Resvg- a fast, small, portable SVG rendering library in rust

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>