Re-evaluate librsvg as SVG renderer on Wikimedia wikis
Open, LowPublic

Description

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.

See Also:
T53555: librsvg seems unmaintained
T120746: Improve SVG rendering

Details

Reference
bz38010

Related Objects

StatusAssignedTask
OpenNone
OpenNone
DeclinedNone
ResolvedKrinkle
Resolvedfgiunchedi
Resolvedakosiaris
Resolvedhashar
Resolvedakosiaris
ResolvedAndrew
ResolvedJoe
Resolvedtstarling
ResolvedJoe
ResolvedJoe
ResolvedJoe
ResolvedJoe
ResolvedDzahn
ResolvedJoe
Duplicatefgiunchedi
Resolvedbrion
Resolvedbrion
Resolvedbd808
ResolvedJoe
DeclinedArielGlenn
ResolvedArielGlenn
Resolvedori
DeclinedNone
ResolvedMoritzMuehlenhoff
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz38010.
bzimport added a subscriber: Unknown Object (MLST).

wmf.amgine3691 wrote:

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.

wmf.amgine3691 wrote:

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?

brion added a comment.Sep 11 2013, 9:37 PM

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.

For the records, chpe (the librsvg upstream maintainer) wrote in a private email that "librsvg is in deep-freeze maintenance mode, and I've been mainly doing minor bug-fix releases."

Menner added a subscriber: Menner.Jan 18 2015, 9:09 AM

There had been an effort to support development of libRSVG which obviously fell asleep.
http://strategy.wikimedia.org/wiki/Proposal:Librsvg_development_funding

This might be revived in by including re-evaluating alternatives.

This test suit is a good starting point to evaluate the quality of a SVG rasterer. One can easily write a small shell script to execute comparisons between different solutions.

http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview

For the records, librsvg seems to receive a bit of maintenance again: https://people.gnome.org/~federico/news-2015-02.html#10

That's great news! Let's hope that besides security (which he mentions on his blog) Frederico will also be working on merging patches / features.

Let's hope that besides security Frederico will also be working on merging patches / features.

He'll review patches but not actively work on new "features" or such, AFAIK

Restricted Application added a subscriber: Matanya. · View Herald TranscriptMay 29 2016, 9:19 PM
Sameboat added a comment.EditedMay 29 2016, 11:10 PM

The bad support of text of RSVG is having a very bad influence to our vector graphic contributors. Font issue aside which has very little to do with RSVG, many SVG contributors prefer to convert text to path due to lack of supports of textPath, writing-mode and really poor scaling and rotating result of text. Even if you scale the SVG image by integral multiplier (e.g. 2, 4, 8), text kerning still looks misinterpreted. If you rotate the text, it just looks bumpy on a rocky road.

There are many downsides of converting text to path:

  • The file size usually is 10x of the pre-conversion version because Inkscape and Illustrator do not know to share path shape of same glyph of same font.
  • Difficult for other contributors to localize the image because they have to re-position all text labels by themselves instead of simply replacing the text.
  • Text can no longer be selectable in real-time rendering by browser.
  • Prevents search engine like Google to search its text.

If GNOME can no longer keep up the bug fixes of RSVG, this would mean Wikimedia will not support SVG created using SVG 2.0 specification which has many important upgrades of its functionality. We need rasterizer because rendering SVG in real-time is still challenging to old computers and Wikimedia is meant to cater to readers in limited circumstances. In the end I hope Wikimedia Foundation can take over RSVG and continue improve it.

Isarra reopened this task as Open.May 30 2016, 5:12 AM

This task is not just about text handling, though that is part of it.

For what is worth, T120746: Improve SVG rendering is the #17 most voted proposal in #community-wishlist-survey. I have asked whether this task is a blocker of that one.

Menner updated the task description. (Show Details)May 30 2016, 5:40 PM
Qgil updated the task description. (Show Details)May 30 2016, 9:31 PM
Qgil set Security to None.

@Isarra Of course I understand. I just want to bump this topic up once again. Mozilla keeps updating its SVG renderer and is even preparing for 2.0. I just want to show my great concern that SVG in Wikimedia is dragging behind due to the inactive/passive update of RSVG. If the Foundation has good funding to use then SVG is one thing deserves the investment. My expectation is very simple: Fix the major bugs/glitches and prep for 2.0.

@Sameboat Sorry, I was referring to Wilfredor closing it as a duplicate of another that's just about text (and also apparently already closed).

That the text rendering problem is so huge is an important point to bring up, and not something I'd even realised was an issue, so thank you for that.

Mozilla keeps updating its SVG renderer and is even preparing for 2.0.

Do you have a link to more information / the code base of Mozilla's SVG renderer?

Sameboat added a comment.EditedMay 31 2016, 9:57 AM

@Aklapper No. As a complete outsider, the only things I actually know about are that Mozilla's staffers are involved in the SVG 2.0 draft and the fact that Firefox has implemented the SVG 2.0 only paint-order property (can be enabled in the stable release, not just nightly). Nonetheless browsers render SVG in real-time, rasterization is a different story.

I have filed few SVG bugs to Mozilla Bugzilla and the most recent one got fixed and implemented in the upcoming stable release.

https://www.w3.org/TR/SVG2/
http://www.w3.org/TR/SVG2/painting.html#PaintOrderProperty

brion added a comment.May 31 2016, 3:52 PM

As far as I know Mozilla's SVG renderer is part of the Gecko web engine (eg, "the entire guts of Firefox"); it's not a separate standalone product. Definitely a possibility to look at using a headless Gecko or WebKit or Blink web engine as an offline rasterizer, though, as I suggested in T56030.

Evaluating a SVG renderer is not a simple task. You need to consider all kind of side effects and find the real needs. I recommend to use this task to find out which are the metrics for such an evaluation.

Yet incomplete I'm evaluating the pain points about SVG. That far I can say the biggest issue is fonts not only the rendering in librsvg but how to use fonts for SVG in general. Another major obstacle is vector graphics in general and the various tool to generate SVG. librsvg issues (besides fonts) are secondary.

(And since Brion is listening, it doesn't cause much effort to fix librsvg issues. Code and project structure is simple. It took me half a day to get into it and I've fixed five bugs in five days.)

@MZMcBride, do you think it would be helpful for us to discuss this as an TechCom-RFC (e.g. have it on the agenda of one of the Wednesday meetings)

@MZMcBride, do you think it would be helpful for us to discuss this as an TechCom-RFC (e.g. have it on the agenda of one of the Wednesday meetings)

Maybe. Highlighting a relevant comment:

wmf.amgine3691 wrote:

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.

Regarding performance, did anything ever happen with the idea presented in T35186#1771760? This task is focused on Wikimedia wikis specifically, so there's a concrete question of how many different SVG renderers we want to support (related: T56030: Support PhantomJS as an SVG rasterizer/renderer option, noted by Brion above).

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?

Mostly this. I think this task is still in "gather the requirements and compare with available options" stage, which may be the full scope/life of this task, as Menner says. Available options would include "free and open source renderer packages" mixed with "code we're willing to run on Wikimedia's servers", of course. And we may end up with more than option that we want to support.

I'm not sure the Architecture Committee would be willing to do the work required to resolve this task, though I suppose it doesn't hurt to ask. :-)

Lemzwerg added a subscriber: Lemzwerg.EditedJul 6 2016, 9:02 PM

Even if you scale the SVG image by integral multiplier (e.g. 2, 4, 8), text kerning
still looks misinterpreted.

Have a look at this librsvg bug report – the bad kerning is not caused by librsvg but by a too old version of Pango (in my case it was 1.36.8). In other words, it is essential for the Wikimedia infrastructure to update to Pango 1.40.1 or something similar – and Harfbuzz should also be a recent version.

Qgil removed a subscriber: Qgil.Jul 7 2016, 9:08 PM
MarkTraceur moved this task from Untriaged to Tracking on the Multimedia board.Dec 2 2016, 10:59 PM
MarkTraceur lowered the priority of this task from Normal to Low.
MarkTraceur added a subscriber: MarkTraceur.

It seems like this has had very little attention, lowering priority.

I created an svg file here: https://commons.wikimedia.org/wiki/File:Uranium_atom.svg
The png version simply deletes all the curved text.
The original svg is fine but visitors to the page will most likely only see the png and will therefore not see a big part of it.

That's T11420: textPath is not supported by rsvg. The workaround is to convert the text to paths. :(

That's T11420: textPath is not supported by rsvg. The workaround is to convert the text to paths. :(

Or avoid using textPaths altogether. But as you say, a discussion for a different task...

Glrx added a subscriber: Glrx.Dec 23 2016, 7:30 AM

okay so you guys don't like SVG's. Fine. But if your software screws up the process of converting it to a png image then why not just allow me to upload an alternate png image for it? I'm sure I can do a much better job. Inkscape allows one to export as png images.

@Just_granpa: If you do not wish to contribute in a positive way to this discussion, I suggest you spend your time on other topics. See https://www.mediawiki.org/wiki/Phabricator/Etiquette for how you can contribute in Phabricator. Thank you for your understanding.

I just offered you a solution to the whole problem. What more do you want?

You can already upload a PNG image and use it instead. That is in no way a solution to re-evaluating librsvg as a SVG renderer, though.