Resvg- a fast, small, portable SVG rendering library in rust
github.comThis library's focus on correctness is what made me realize how absurdly complex SVG rendering is.
They focus only on static SVG, and only on SVG 1 (though apparently they're working on SVG 2 support) and they still only manage to pass something like 90% of the tests.
Which is more than any of the popular browsers or SVG rendering libraries. I wouldn't be surprised if resvg were the most compliant SVG renderer in existence.
And that doesn't even take into account the actually complicated parts of SVG, like requiring an entire JavaScript interpreter for the <script> tags, which resvg rightfully excluded from its scope.
These decisions made sense for the web, I guess, where all of the pieces were already there. The browsers already had to handle native text rendering, JavaScript, etc. It seems like SVG became something like a common interface to the drawing primitives browsers had anyway. Plus JavaScript.
I'd like to see a much smaller, embeddable vector graphics format that doesn't require a whole browser to implement it.
Agreed. At some point, there was a plan for a profile of SVG that dropped CSS, scripting, filters, and other such ideas but I don't think it ever got published.
SVG2 has been in development for over 10 years, and there are still TODOs in the draft spec that range back that long, for some pretty core things. And it's only grown in scope, too. I'm disappointed with the SVG WG's direction, and the browsers probably won't try to implement much of it.
Many SVGs can "fail gracefully" though, like you can have a huge SVG with all these embedded whatevers, but still render it with like 80-90% fidelity if you just ignore the parts you don't want to support. Not good enough, right? Until you consider that the web itself is similar... every browser just does its best guess of intent, given a poorly standardized syntax and incompatible renderers. Maybe it's a little better now these days, with strict modes and doctypes and caniuse, but it's still far from perfect. Add in JS and API differences between WebKit and Blink and... don't ya miss Flash? ;)
SVG was meant for web (vs, say, PostScript or EPS), so for it to be useful dynamically, it always had to support some subset of the DOM styling systems... namely CSS and XML-like structure. Once you had that, though, it was only expected that embedded fonts, masks, filters, etc. would come too, iterating alongside the web itself. Then, its instability becomes a double-edged sword... like the web, it constantly gains new features; like the web, it is incredibly difficult to standardize; and like the web, no two platforms will ever display a single SVG quite the same.
SVG was never meant to be a stable archival format for vectors, just a way to represent controllable shapes on the web alongside text and rasters. It's not a "PDF for graphics" format, more like a "vectors and controllability for web" format.
If its expected target output is the web, it makes sense that web browsers would be the expected renderer. Just like you wouldn't use HTML Canvas to share rasters between desktop apps, there's not really a good reason to use SVG to share vectors outside of the web. A lot of vector graphics programs support some subset of SVG features, but very few of them can properly utilize its underlying power -- an embeddable, controllable part of the DOM -- as opposed to treating it like any other "dumb" vector format.
<side rant> If you actually want something archival-capable and readable later on with full fidelity, some older version of .AI is probably safer? It's easier for a single vendor to maintain backward compatibility than for an entire ecosystem of independent open-source teams to try to parse and guess at each other's specific subset of SVG features & implementations, all while the format itself keeps changing. Sometimes the proprietary stuff actually has value... whether it's SVG vs AI or OpenOffice XML vs Word, the single-vendor solutions are far better at maintaining document fidelity over the years. Yes, that sucks, and oftentimes the vendors will go out of way to embrace, extend, extinguish the open formats (moreso Microsoft than Adobe), but really, once Flash was gone, the web lost its only truly interoperable vectors interchange format. SVG is just what we're left with, not what's best. </side rant>
Archiving vectors is an interesting problem worthy of far more than a side rant. The wonderful thing about things like this render is actually being able to store a simple a stand alone viewer/renderer to ensure the ability to view the files correctly in the future without worrying about the rest of an entire web browser.
I make use of a library in R to render SVG that uses Cairo to render to an intermediate (simplified) format, which looks a lot like what Resvg is doing with usvg. The advantage here seems to be that this is a much more compact library (fewer dependencies maybe?)
Does anyone know if rust plays well acting as the backend for R libraries?
How does this rendering/simplification compare with Cairo? I’m wondering if this is a fun summer project for some student!