On Thu, May 5, 2016 at 9:49 AM, Brion Vibber bvibber@wikimedia.org wrote:
Rendering consistency across browser engines is a concern. Supposedly modern browsers are more consistent than librsvg but we haven't done a compatibility survey to confirm this or identify problematic constructs. This is probably worth doing.
There's also the font issue: with the current rasterizing, only certain free fonts are available and we know what it falls back to. Serve the SVG to the client and those free fonts may well be missing (falling back to who-knows-what), while other fonts with different metrics that our rasterizer ignores might be present on the client.
And we'll almost certainly want to strip comments and white space to save bandwidth on page views, while retaining them all in the source file for download and reediting.
There's other stuff that could be stripped, too. For example, Inkscape's default "Inkscape SVG" format saves a lot of extra data under its own "inkscape" and "sodipodi" namespaces and some style rules with a '-inkscape-' vendor prefix that we could probably kill.
Inkscape also likes to put 'id' attributes on absolutely everything (e.g. rect3342, tspan8263), which we could strip if we can somehow determine they're not used somewhere else (including <style> or external reference of some sort). It also likes to be redundant with inline CSS (e.g. reiterating defaults, including all stroke-* properties despite stroke:none meaning they're unused), but that's even more problematic to determine whether it's safe to strip.
Some of the stuff in the svg:metadata node could probably also be killed, although we might want to preserve some pieces (e.g. license, author) even in minimized form and/or add some of our own (e.g. URL of the file description page where the original can be downloaded).