On Thu, May 5, 2016 at 9:49 AM, Brion Vibber <bvibber(a)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).
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation