Last modified: 2014-05-29 19:48:39 UTC
I don't know the exact history, but at some point Wikimedia wikis added the ability to support inline SVGs by passing them through librsvg, which takes the SVG code and generates PNGs, as I vaguely understand it. There are some notes here: <https://meta.wikimedia.org/wiki/SVG_image_support>. I can't find any information about which version of librsvg Wikimedia is currently using, but the choice of using librsvg should be re-evaluated, given its rendering issues (cf. other bugs in this bug tracker) and the existence of perhaps better alternatives.
As pointed out at http://www.mediawiki.org/wiki/Manual:Image_Administration#SVG there are multiple methods of rendering svg. The justification for rsvg at times in the past was primarily speed, with other renderers being found more accurate, stable. This has been extensively looked at in the past, but *perhaps* it is time to review the options, especially considering some of the sources used date from 2008. (Currently I use Inkscape due to inkscape-specific extensions to svg.)
reedy@fenari:~$ rsvg --version rsvg version 2.26.3 (Wikimedia) There are a couple of svg/rsvg related bugs tagged against bug 36623
One also needs to consider the number of files that have rsvg hacks in them, or at the very least only look pixel perfect in rsvg. Having tried a few of these, I think Inkscape is probably the only viable alternative, but it would need performance testing.
https://mail.gnome.org/archives/gnome-announce-list/2010-May/msg00000.html > Date: Sat, 01 May 2010 21:17:19 +0900 > librsvg-2.26.3 is available now. Perhaps we should try upgrading ? I know we filed a lot of bugs upstream at rsvg in 2010, but if we don't upgrade, we won't get the fixes of course.
Lucid (Ubuntu 10.04) is on 2.26.3 Precise (Ubuntu 12.04) is 2.36.1 Waiting on the upgrades to 12.04 (bug 36623) is probably worthwhile, and we can rebuild our rsvg against that version, or just use that as stock. Changelog: https://svn.wikimedia.org/viewvc/mediawiki/trunk/debs/librsvg/debian/changelog?view=markup Patch: https://svn.wikimedia.org/viewvc/mediawiki/trunk/debs/librsvg/debian/patches/wikimedia-brand.patch?revision=109758&view=markup ^ will need applying if we've changes like below (simple) https://svn.wikimedia.org/viewvc/mediawiki/trunk/debs/librsvg/debian/patches/no-external-files.patch?view=markup&pathrev=109758 ^ Doesn't seem like it was upstreamed, so would need re-applying against a newer version. It also (unsurprisingly?) doesn't apply cleanly to 2.36.1 from their git repo
Upgrading librsvg won't fix it, at least not yet. librsvg 2.36.1-1 still seems to have most of the relevant rendering bugs we run into on these projects; at very least it's been what I've been using for debugging messed up ones and to test if svgs will render properly before uploading them and it hasn't been wrong yet. The problems rsvg picks up, however, are often with the svgs themselves - strange node positioning, weird objects, and things like that which can be enough to confuse it. But while these issues are fairly easily fixed in the files, rendering problems stemming from just how much librsvg rounds things down cannot; anything using blurs or precise positioning is apt to render poorly, especially at lower resolutions, because the relevant information can wind up either truncated or chucked entirely. See https://commons.wikimedia.org/wiki/File:MediaWiki_logo_1.svg for an example. Inkscape, on the other hand, while usually quite lovely, sometimes gets confused and puts random holes in things, though this can be also worked around by breaking apart affected objects.
For what it's worth, we upgraded image scalers to precise last week, so we run 2.36.1 now.
What are the exact criteria to evaluate against, in order to get this ticket fixed? Currently this sounds unfixable due to vagueness.
Available options are ImageMagick, ImagickExt, sodipodi, inkscape, batik, rsvg, and imgserv. My understanding is: rsvg was the worst image quality, most difficult to install/maintain, but the best performance, and for this reason was selected and is currently used by WMF. So, the criteria would be: what is the ordered priorities to use in judging svg conversion (presumably 1. conversion performance, 2. maintenance cost, and 3. image quality); what are the ranked performances of the available options; if, after summing the performances of each option (weighted by ordered priority), rsvg is no longer the best choice, does WMF migrate to the better solution?
fwiw http://www.mediawiki.org/wiki/SVG_benchmarks
Note bug 54030 -- we could put together a local daemon that runs PhantomJS and have it render SVGs with WebKit. :P
Security is also a consideration. The solution must be able to be sandboxed and have its http fetch neutered. rsvg is designed for embedded solutions and has good controls for this. It would be much harder to sanitize/sandbox some of the other solutions.
