(Warning: bit of a tangent)<p>Conceptually, I love this.<p>Mainly because for some reason it irritates me than screenshots are bitmaps.<p>Nearly everything in a user interface or document is vector-based, except for photographs and natural-media illustrations.<p>The ability to capture part of a webpage as an SVG feels like a step forwards in preserving vector content.<p>My real wish is that OS interfaces would be just as vector-based, where rendering to bitmap was just something the OS handled at the end. So a screenshot in macOS or Windows would similarly always be SVG.
We used this to generate dynamic share cards for our core web vitals checker tool (plug: <a href="https://calibreapp.com/tools/core-web-vitals-checker" rel="nofollow">https://calibreapp.com/tools/core-web-vitals-checker</a>).<p>Previously new uncached requests for Open graph share-card images were generated in Chrome, sometimes taking up to 5 seconds to generate. (They were then stored in cache for 12 hrs).<p>Because we're now using Satori powered og images, they render almost immediately and we don't have to own the problem of having Chrome deployed within the 50mb lambda limitation. I'm pretty happy about that.
You can do something like this via the browser by printing the page to PDF then using Inkscape to convert that to SVG. I documented this here: <a href="https://www.checkbot.io/article/web-page-screenshots-with-svg/" rel="nofollow">https://www.checkbot.io/article/web-page-screenshots-with-sv...</a>. There's a few caveats though like box-shadows getting converted into bitmaps and vectors not being grouped in layers like you'd expect, plus it's heavyweight if you're wanting to script it.<p>I'm curious if Satori could be used to capture in-app client-side screenshots accurately.
I recently implemented a similar concept to this for HTML emails at shortwave.com, it only works for the subset of non table emails (which we assume are marketing emails and you want to see the full HTML). It allows us to render stuff wayyy faster (especially on mobile where webviews are not cheap). We don't go all the way to pixel layout because we want to have some responsiveness, but it allows for heavily normalized emails (no more neon yellow on a green background with comic-sans font) and some other neat optimizations.<p>Didn't use yoga but a from scratch implementation. A good starting point is let's build a browser engine [1]. I hope to blog about it at somepoint.<p>[1]: <a href="https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html" rel="nofollow">https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.h...</a>
Interesting.<p>I was thinking that this was going to be a crazy amount of layout engine work, but now I look a little closer it <i>appears</i> the layout work is farmed out to yoga [0] (not trying to take away anything from the effort here). So this project is almost a wrapper around running yoga as a renderer and using SVG as a form of backend target?<p>I say "appears" because the yoga landing page doesn't do a great job of explaining what it does.<p>EDIT Just looking at some of the information about the font side of things and the naming is a little confusing. You set embedFont=false to use text instead of converting the text to paths. embedFont=true sounds a lot like it will embed the _font_ required to render the _text_ - but it <i>kinda</i> does the opposite.<p><a href="https://github.com/vercel/satori#font-embedding" rel="nofollow">https://github.com/vercel/satori#font-embedding</a><p>[0] <a href="https://github.com/facebook/yoga" rel="nofollow">https://github.com/facebook/yoga</a>
Converting text to SVG is super hard. Flowing English text is easy enough, but when it comes to Unicode text, with languages such as Arabic and Indian languages, that's when it gets hard. I tried Satori, and it doesn't handle Unicode very well, particularly, combining characters.
Love the project! Sorry to be pedantic, but the claim is <i>technically</i> false. You don't actually support HTML and CSS. You support JSX. As someone who doesn't use React due to the abomination of mixing html and css within the JS, do you have plans to actually support regular HTML and CSS? Or provide a dedicated transpiler? (I'm not familiar with the react ecosystem, so likely one already exists?)
Alright, I like this, almost a lot!<p>In the 90's there was a vector graphics editor called Satori. It was something beyond the understanding of us neighbourhood kids. Something beyond the Paint (and Paintshop Pro). Now let's get back from the nostalgia trip...
Does the tailwind support work with className declaration?<p>I would like to use it with existing component library which is built using tailwind without making changes. Is that possible?
This would have been great for that one time I found a html+css copy-paste script for styled multiple underlined text. Doing it in LaTeX/tikz directly would have taken me hours.<p>The html+css looked fine, but to get it to a vector image as required by the journal was a pain: print to PDF, find out the lines aren't reproduced correctly, manually find a PDF printer with the right settings, convert to eps
Some of what looks challenging here is handling fonts. SVG would be so much better if there was a way to do font embedding. Even a minimal set of fonts would be amazing. Or if operating systems or libraries for SVG support could all commit to supporting a common set of fonts, like browsers did for web safe fonts. Think of how clunky the web would have been without those.