Page MenuHomePhabricator

Improve SVG rendering
Closed, ResolvedPublic


SVG is an important file format for graphics on Wikipedia and is used in thousands of science articles. And this also the underlying software libRSVG has many problems with rendering SVG even the article about force in german (de:Kraft) is affected.

The issue arises since libRSVG was programmed by the Gnome Project to render scalabe icons for their desktop environment. Graphics that contain text was not a goal and activities around libRSVG are limited to maintenance today. Because of that important features required for usage inside Wikipedia are buggy or missing. Some bug reports and feature requests by our community are undone since nearly ten years. A test of my own showed that fixing an issue often takes only few days (see T7792: rsvg does not render baseline-shift correctly (<percentage> and <length>)

SVG is important to Wikipedia but without our intervention the underlying software stays error prone.

Another big example...

The file on the right is used by en:Gas tungsten arc welding and in many more languages and even translated. It provoked bug described by task T97758: SVG rendering with marker-element is different between librsvg and Inkscape. Due to its long endurance on Wikipidia it has been shown to our readers many million times. (A workaround has been applied to render it correctly recently.)


To get an overview about the importance of a file format some statistic is useful. Based on database dump dewiki-20150302-pages-articles.xml.bz2 of german language Wikipedia the following estimation can be done. (Only short evaluation about systematic errors has been done.)

SVG: 56k
PNG: 92k (similar scope as SVG)
JPG: 1104k (mostly pictures)
GIF: 10k (similar scope as SVG)

Results have been gained with Linux tool en:grep. To change to another file format adapt the following command line call. date && grep -o -E "(gif|GIF)\|(thumb|mini)" ./dewiki-latest-pages-articles.xml | wc -w && date (Only counts images that are embedded as thumb preview and not e. g. all the small flags in sport statistics.)

Which users would benefit?

Everybody who is researching scientific or technical information on Wikipedia of any language will benefit. SVG is the preferred file format for high quality science graphics.

It will increase participation because less errors in SVG rendering removes pitfalls for authors without experience in the limitations of libRSVG. As consequence less distraction is created and new authors keep contributing.

This also increases quality because less errors in SVG renderer switches focus from workarounds to content. SVG simplifies re-usage and translation of content and high quality graphics can be share across languages. Thus improving and promoting SVG pushes quality.

How is this problem being handled now?

The SVG renderer libRSVG is part of the Gnome Project. Although it is not in the focus of the Gnome community as it does its job for their purposes. The Maintainer of libRSVG is Federico Mena Quintero. He maintains libRSVG in his spare time.

What are the proposed solutions?

Fix around eight to ten bugs that are especially important for usage of SVG on Wikipedia. Fixing only a few simple bugs would reduce the pain greatly. I expect this to require four weeks of work for fixing bugs, test them and manage software release. (In case fixing libRSVG code is beyond the capabilities of the Tech Team at least managing existing patches would be helpful.)

  • Menner (talk) 20:04, 9 November 2015 (UTC) I'll support selecting bugs, mastering libRSVG code and software release, too.

This card tracks a proposal from the 2015 Community Wishlist Survey:

This proposal received 46 support votes, and was ranked #17 out of 107 proposals.

See Also:
T40010: RFC: Re-evaluate librsvg as SVG renderer on Wikimedia wikis

Event Timeline

DannyH raised the priority of this task from to Needs Triage.
DannyH updated the task description. (Show Details)
DannyH subscribed.

The biggest single thing that could be done to improve SVG rendering would be T112421, but apparently they're run into several regressions that would need to be tackled first.

IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.

Fix around eight to ten bugs that are especially important for usage of SVG on Wikipedia.

Assuming most work would have to happen in the librsvg library (GNOME Git instructions), this requires someone who knows C.
Plus getting patches reviewed and merged in upstream which might turn out as a bottleneck as Federico (upstream maintainer) is short in time.

Is there agreement which bugs are "especially important" for Wikimedia, to break this task down into some more 'actionable' parts?
I triaged most of our SVG tasks yesterday hence wondering if the priorities of our open tasks are 'correct' and if some tasks should be upstreamed to librsvg (if there is no upstream report yet).

Is there agreement which bugs are "especially important" for Wikimedia, to break this task down into some more 'actionable' parts?

@Menner: Do you know, looking at the open tasks?

T40010 is a request for evaluation. Since there hasn't been a evaluation between available options I wouldn't call it a blocker. In fact T40010 is a subset of this Task. Improving rendering may lead to evaluate alternative options.

You can improve SVG rendering also by improving librsvg instead of getting rid of it.

The biggest single thing that could be done to improve SVG rendering would be T112421

This task (upgrading Wikimedia servers to librsvg 2.40.16) got fixed last week by Moritz, which resolved / improved several issues.

I'm still wondering about more specific success criteria for this task (when one could be able to declare victory, basically). The task description currently says:

Fix around eight to ten bugs that are especially important for usage of SVG on Wikipedia. Fixing only a few simple bugs would reduce the pain greatly.

As mentioned in T120746#2102447 and T120746#2275732, how to identify eight to ten "especially important" tasks?
@Perhelion, @Menner? Anyone else specifically interested in SVG support?

It's heuristic to identify important tasks. One topic is minimize issues with fonts since their handling is diffcult even in a world without bugs. Another source are the archives of graphics village pump on Wikimedia. The last critiria is thinking about what issue would annoy beginners most.

Since SVG2 is on the rise and librsvg is loosing touch (Re-)evaluation of SVG renderer is the top topic for me.

SVG is a long and may be never ending story...

Three issues in librsvg (the software library used to render SVG files on Wikimedia) got fixed since this wish was raised, one issue got fixed partially, one is being fixed/reindexed, according to

The original proposal talks about eight to ten bugs to fix.
As per the last comments in this task we're unfortunately missing clear criteria and input what else is especially important to our communities when it comes to SVG rendering - it currently looks like nobody plans to prepare a list of specific issues they would like to see being worked on.

Hence I am going to close this task as resolved, as SVG rendering has improved a bit in the last months.

Obviously there is always more to fix (as in every software project which isn't perfect). So if you have further specific problems in mind that should get fixed, I strongly encourage you to propose specific SVG issues in the next upcoming Community Wishlist survey which will probably start in November 2016.

Thanks a lot to everybody who helped improving SVG rendering on Wikimedia so far! :)