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.
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.
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>
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!
