If you're curious, it's called StageKeep, and you can find it here. https://stagekeep.com/
The original project used React Three Fiber, but refactored it to SVG for reasons I don't quite remember. I was inspired by signed distance functions, and the fact that one function could have such an outsized visual effect. Although the software doesn't use SDFs, but I like the idea of atomic functions that accepts some input, and outputs SVG.
I wish I was a dancer.
That said, the founder who hired me to work on this is a dancer.
He hired me because he liked the fact that during the interview, when asked "what do you know about dance", I responded "I used to crip walk when I was in high school", so I was the top choice just for that, haha.
Edit: the Founder is Axel Villamil, and he's super charismatic. Y'all are going to love him. Here's him trying to raise an investment round https://www.instagram.com/reel/CyhL5kitUbD/
I decided to "roll my own" and write Python scripts that outputted SVG markup. I was worried this would go about as well as every other "roll your own" project does, but was pleasantly surprised. It is surprisingly easy to output reliable, good-looking SVG graphics using Python. If you are making a chart, everything is just math.
The infinite scalability is almost just a happy upside to the simplicity of creating the visualizations, which is annoying in raster format. It made me like SVG even more.
It's from the creator of D3 and it's much easier than using raw D3. I've been using it outside the Observable platform for debug charts and notebooks, and I find its output crisp and its API very usable.
It doesn't try to have all the bells and whistles, and I'm not even sure if it has animations. But for the kind of charts you see in papers and notebooks I think it covers a lot.
PDF may have "officially" replaced it, but it is still embedded almost everywhere you look.
(There was some justification in terms of 'Oh, a binary format like PDF is more space efficient.' But PDF never really was more efficient than compressed PS.)
It's not that PS has vanished, but PS isn't nearly as 'everywhere' as HTML came to be.
But it was not all that good as a way to send documents to be printed elsewhere. Postscript files were in some ways too dependent on the printer they targeted, so the person creating the PS file had to know too much about the printer that would be used to print it: its resolution and optimal halftone screen frequencies, media sizes, etc. With high-resolution output on photographic film costing around $10 per foot, mistakes could be expensive as well as time-wasting.
Fonts could also be a problem. Ideally, the PS file would contain all the fonts it required but this did not fit very well with the terms of most font licenses. And some applications would include a copy of every font used once on each page on which it was used. This was in line with Adobe's recommended Document Structuring Conventions and had the advantage of making pages within the file independent of one another, but for documents with hundreds of pages, this could add up fast and make the PS file literally hundreds of times larger than if all the fonts were included just once. With small storage media and slow network links, this was a real problem.
The "P" in PDF is for portable, and these are the problems it solved. Unlike a PS file, a PDF file is not targeted for a specific printer model, and most font licenses allowed the licensee to include subsetted fonts in PDF files. I personally prepared PS files for a few thousand books to be printed at various places around the US and later, PDF files for thousands more. There is no comparison: PDF was and is better in every way for this purpose.
It is extremely useful to have a full programing language as a file format, though.
I miss macOS’s Preview.app auto-converting PS to PDF when double-clicked. It was a way to easily distribute a document that could randomize question orders each time it opened, print multiple bingo cards from a single file, etc.
The stack-based and reverse Polish notation thing was also fun.
""" In my idealistic vision of how scientific publishing should work, each paper would be accompanied by a fully interactive environment where the reader could explore the data, rerun the experiments, tweak the parameters, and see how the results changed. """
I do like seeing larger labs/companies releasing research full of SVGs. In recent memory, I quite liked this from NVIDIA:
The idea of being able to view and parse the dataset in different ways is interesting though, effectively allowing readers to interpret the experiment's resulting dataset from different angles than the author published.
Without interactivity, postscript is vector graphics too.
Anyway, of relevance to this thread is that the controller connected to the local wireless network and provided an embedded HTTP server with an SVG based web UI that would graph temperatures and provided actual knobs and dials so that the controller could be tweaked. SVG in the browser works nicely with Javascript.
(Outstanding work by Shan Carter; it’s what I first saw of his style and it’s what made me want to join his team.)
[0] https://distill.pub/2016/augmented-rnns/ [1] https://github.com/distillpub/post--augmented-rnns/blob/mast...
- cannot wrap text
- cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how? Photoshop solved this long time ago - it saves both text and its rendering, so the text can always be rendered.
- browsers do not publish, which version and features they support
- may contain Javascript and references to external resources, which makes it difficult to view in a secure, isolated environment
One of solutions is having two SVGs: author version, which you edit in Inkscape and which uses Inkscape-specific extensions, and published version, which is generated from the first, that uses only basic features and has text converted to curves.
- They often render differently in different browsers and other renderers. It's very frustrating to get consistent results (like a PDF). In complex diagrams I'd say it's basically impossible
- Renderers that are fast usually lack many features
- Nobody other than the browser seems to actually have all the features?
- You can link an SVG within an SVG (to make a lightweight composite image). But if you have two levels of indirection then all renderers I've tried will refuse to render the SVG
- Inkscape is basically the only good editor on Linux and it easily runs out of memory and crashes for complex images
- Complex SVGs eat all your RAM in Chromium (only marginally better in Firefox)
- Basic things like arrows from Inkscape will not render anywhere else
I still use SVGs all the time, b/c there are no good alternatives, but it's a crappy standard and I try to keep all my images/diagrams extremely simple
Like for QR Code, precise maps or +100 pixels wide squares. More than 100 "DOM" elements and it will take multiple seconds to show.
The animations also are slow too, compared to canvas, plain CSS or Lottie but nothing very cursed, it's mostly fine.
This was done for a friend of mine who made an art installation that projected like some 50x20 (can’t remember exactly) of these images in a grid on a wall, for perpetual chess madness.
The number of chess SVGs a laptop’s browser was able to run simultaneously did feel suprisingly low, but luckily it was enough for that particular piece of art.
So a SVG you authored 20 years ago for some browser will likely work everywhere today.
I was prototyping an orrery. It involved cutting out a lot of ad-hoc gears and frame bits on my CNC out of a sheet of brass. It was relatively easy to generate the g-code for the individual parts using fusion360, but then it was a lot of faff to zero the machine such that it cut the part from a fresh part of the brass sheet without wasting too much metal in between the parts. It involved a lot of guesswork, and eyeballing. And even with that there was a lot of brass “wasted” between the parts especially since you could only move your part in x-y but not easily rotate it.
As a solution I wrote a python script which converted the g-code into svg, and a simple one page website where i could drag the svg around and rotate it on a visual representation of the sheet. Once i found a good safe spot for it to be cut the page told me the x,y, theta coordinates for it. And then with a separate python script i could transform the g-code using the coordinates and rotation. This way the svg renderer was doing the heavy lifting of visualising the cutting paths, and i only needed to concentrate on the relatively easy transforms.
https://github.com/shapeoko/Docs/blob/gh-pages/content/tPict...
Used to be if that was opened in a web browser one could click on the parts list to show/hide or highlight/unhighlight the matching items in the diagram.
Done using Inkscape if memory serves.
ALSO I've run into security reviews that flag inline SVGs because they can embed scripts... would love to see more tooling to lint and sanitize them before deployment.
BUT seeing a two-decade-old vector still render correctly gives me confidence that the core spec is solid.
Sanitisation is one of two possible defences, the other being script execution controls or sandboxing. E.g., if you serve vector images on a web server, set a Content Security Policy header¹ for all your images that simply denies all scripting. You can also run it from a dummy domain ('origin') with nothing valuable on it (like how domains such as googleusercontent.com and githubusercontent.com are being used)
For sanitisation, DOMPurify² is the only widely used and tested library that I know of. It could use more bindings for other languages but, if you can call into it, it can go in your deployment pipeline. (Disclosure: I've worked with some of the people at Cure53, but not on this project)
You can also combine the approaches for defence in depth
¹ https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
Did you see?:
Except they aren't. I recently used a simple SVG in a background and Safari wasn't able to render it properly so after trying lots of different things I gave up and used different sizes of raster images instead.
github: https://github.com/davefowler/markdown-svg playground: https://markdown-svg-production.up.railway.app
Anyways, impressive, but what I’d really love to see is flexbox for SVG ;)
We use SVGs on https://typequicker.com/press for the blog post hero images.
This way - even if the user changes themes, the colors of the image will be consistent with whatever theme is currently active. Also - the loading time is near-instant since we don't need to fetch the img file for the blog post image - just render the svg.
Is there a way to embed the data encoded in the QR code directly within the image? This would allow the data to be parsed directly by the browser, eliminating the need for computer vision to decode it again. Going further, for web images QR codes could be efficiently encoded and rendered by the browser.
SVGs are XML so technically, yes, you can just embed your visually encoded payload data with namespaces attributes and elements. If you don't want to use namespaces, you can use off-canvas texts, hidden/opacity=0 texts or even XML comments. You can even use the regular metadata section of SVGs. You can make the whole QR code within the SVG a clickable link.
Why? svgomg.net exists, uses far fewer resources, and is going to give you much better results.
I tried with ChatGPT and Claude but both were not able to find a solution that respects the entire specification, especially transforms.
Initially, my expectation was that there must be a library for this kind of thing, but alas.
https://pypi.org/project/svg.path/
But there seems to be a lot of SVG specific tooling and code to do this in python?
Sorry that's not more useful and explicit, it was a while back and never went anywhere.
The algorithm provided a 100X performance improvement over the classic Monte Carlo stuff that Tokyo had written.
The charts in the document were executable Postscript, running his algorithm.
That got the attention of the Ph.Ds in Tokyo. He was a high school-educated neurodivergent.
https://www.cloudflare.com/cloudforce-one/research/svgs-the-...
Odd thing to say. Everything on a computer is "essentially code", executable or not.
Libraries like three.js had SVG rendering as an option but it got deprecated as <canvas> with more direct GPU APIs was a lot more efficient and flexible.
But can it read email? https://www.laws-of-software.com/laws/zawinski/
- https://mlu-explain.github.io/neural-networks/
Simple? No. SVGs are not simple. If they were simple they weren't so capable.
TLDR:
- SVG image files: powerful like HTML
- Supported widely in browsers
- Designer tools make SVGs
- SVGs are written in a language
- LLMs are great at manipulating language
- Designers can collaborate interaction into life