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
T10901: SVG rasterisation and management on Wikimedia sites (tracking)

Details

Reference
bz38010

Related Objects

StatusAssignedTask
OpenNone
DuplicateNone
DeclinedNone
ResolvedKrinkle
Resolvedfgiunchedi
Resolvedakosiaris
Resolvedhashar
Resolvedakosiaris
ResolvedAndrew
ResolvedJoe
Resolvedtstarling
ResolvedJoe
ResolvedJoe
ResolvedJoe
ResolvedJoe
ResolvedDzahn
ResolvedJoe
Duplicatefgiunchedi
Resolvedbrion
Resolvedbrion
Resolved bd808
ResolvedJoe
DeclinedArielGlenn
ResolvedArielGlenn
Resolvedori
DeclinedNone
ResolvedMoritzMuehlenhoff
There are a very large number of changes, so older changes are hidden. Show Older Changes
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.

resvg is faster and renders better than librsvg, see benchmark: https://github.com/RazrFalcon/resvg/

Also resvg improves faster than rsvg.

Programrender timeTests passed
resvg150 s (best)221
rsvg 2.42.2242 s202 (worst)
Inkscape1610 s257
Batik3686 s254

Practically speaking, resvg seems to not be packaged in Debian. That is something to solve first.

Reedy added a comment.Jul 17 2018, 9:26 PM

As a side note, resvg isn't packaged for debian

Krinkle updated the task description. (Show Details)Jul 17 2018, 9:28 PM
Krinkle updated the task description. (Show Details)
Krinkle removed a subscriber: wikibugs-l-list.
MichaelSchoenitzer added a comment.EditedJul 17 2018, 9:31 PM

resvg seems the by far most promising alternative available, it's faster, saver and renders better than librsvg in most aspects and the software-architecture seems more future-proof.
But it's also a very young project – therefore the missing debian-package – and up to now a one man project. It's therefore probably to early to switch.

You can find background about resvg here: Libregraphicsworld: introducing libresvg

Glrx added a comment.EditedJul 17 2018, 11:42 PM

At this point, we should not use resvg even if there were a Debian package.

I went down the support table at

https://razrfalcon.github.io/resvg-test-suite/svg-support-table.html

I looked for significant features where support differs (resvg XOR librsvg) but also comment on important features.

Resvg may be fast, but it will fail to render many images on Commons that librsvg handles. Resvg also does not offer significant support beyond what librsvg has, so it does not offer a significant benefit to counter the failed images.

For Commons, a renderer must support BIDI, markers, and systemLanguage. Resvg does not.

Supporting textPath and writing-mode would be pluses, but Resvg does not do that either.

Switching would cause trouble with little benefit.

FEATURE COMMENTS:

resvg does not support systemLanguage but librsvg does (with bugs). A step backward. Multilingual SVG dies.

resvg does not support marker but librsvg does. Lots of diagrams with arrowheads would die. (also marker-start attributes.)

resvg does not support textPath; neither does librsvg. textPath would be a reason to switch; it is a big failing of librsvg.

resvg does not support filter effects; I believe librsvg has some support but I'm not sure.

resvg does not support baseline-shift; librsvg has some support (and may now support all). Say goodbye to sub- and superscripts

resvg does not support alignment-baseline; neither does librsvg.

resvg does not support dominant-baseline; I doubt librsvg does.

resvg does not support direction; librsvg does support direction (but messes up on text-anchor).

resvg does not support a font-list; librsvg does (but gets confused by quotation marks). A step backward, but a minor one if the first font is used; a more significant problem if resvg goes looking for a font by the name of "Arial, Liberation Sans".

resvg supports ex; librsvg does not. A minor benefit; most lengths are in px and em.

resvg does not support font-variant; neither does librsvg. That means no small-caps support.

resvg supports relative font weights; librsvg does not. A minor benefit; most diagrams will say "normal" or "bold".

resvg does not support letter-spacing; librsvg does. A half step back. Letter spacing is used on maps.

resvg does not handle overflow; librsvg does. Inkscape cheats on markers with overflow=visible (but resvg does not do markers....)

resvg does not do Unicode BIDI; librsvg does with some errors. Possibly two steps back. RTL languages often have ltr numbers with metric units (e.g. 10 km).

resvg does not do writing-mode; librsvg tries; rtl may work but fails on tb (e.g., vertical Chinese). (librsvg has text-anchor issue).

librsvg is under heavy development since it was converted to a Rust project; it now comes with tests also. Has someone already checked recent versions (e.g., 2.43.2) whether there are improvements for the stuff Wiki needs? Have been issues opened on the important bugs which are still present?

JoKalliauer added a comment.EditedJul 18 2018, 7:07 AM

@Lemzwerg :
Updateting librsvg 2.40.16 to 2.42.3 or higher would fix

librsvg 2.40.19 requires Pango 1.38.0 and libxml2 2.9.0. (According to @kaldari )
librsvg 2.41 and higher requires Rust (As already pointed out)

@Glrx : If we only talk about renderingquality, we might should change to Inkscape.

@all: Would it possible to set a flag, that a picture should be rendered with a different library, that we have librsvg for default, but for special cases Inkscape? (f.e. File:Dojikko2.3.svg

Has someone already checked recent versions (e.g., 2.43.2) whether there are improvements for the stuff Wiki needs?

For the records, T193352#4166886 describes the problem to first solve in Debian for deploying librsvg ≥2.42 on Wikimedia servers (which won't stop anyone from testing locally with such newer versions).

Have been issues opened on the important bugs which are still present?

You can get an overview by going to the Upstream board at https://phabricator.wikimedia.org/tag/upstream/ and then using an "Advanced Filter" it to only show Wikimedia-SVG-rendering tickets to see what is reported: https://phabricator.wikimedia.org/project/board/153/query/Ban8ce9_KOGu/
Same for using the Wikimedia-SVG-rendering board and filtering for (not in) upstream to see what's not reported: https://phabricator.wikimedia.org/project/board/211/query/mzVIaLq0ZosO/

If we only talk about renderingquality, we might should change to Inkscape.

I don't understand. Inkscape is not a rendering library but an image manipulation application that uses librsvg as its rendering library (at least on Fedora).

librsvg 2.40.19 requires Pango 1.38.0 and libxml2 2.9.0. (According to @kaldari )
librsvg 2.41 and higher requires Rust (As already pointed out)

Both require the Thumbor servers to be upgraded to Debian stretch first; this provides recent enough versions of Pango and libxml.

Also, in the Strezc 9.5 point release that happened last weekend, rustc was updated to a release which is recent enough to build the Rust-based versions of librsvg: https://packages.qa.debian.org/r/rustc/news/20180705T110012Z.html

While the migration to the Rust-based version is blocked in Debian by a lack of support on some architectures, none of those are relevant to the servers run by WMF.

JoKalliauer added a comment.EditedJul 18 2018, 7:24 AM

I don't understand. Inkscape is not a rendering library but an image manipulation application that uses librsvg as its rendering library (at least on Fedora).

Inkscape can also batch-convert SVG2PNG:

inkscape file.svg --export-png=file.png --export-dpi=96

@Aklapper: please check:
Category:Librsvg_bug_replaced_by_bitmap_graphic
allmost all pngs are rendered by Inkscape, also it is based on librsvg, but it supports f.e. textPath, complicated filters (f.e. |File:Vergleich_zwischen_Manga_und_Foto_(nur_Zeichnung).svg, librsvg not.

@Aklapper : Please check: https://www.mediawiki.org/wiki/SVG_benchmarks

hashar removed a subscriber: hashar.Jul 18 2018, 9:07 AM
Glrx added a comment.Jul 18 2018, 3:53 PM

@Glrx : If we only talk about renderingquality, we might should change to Inkscape.

A similar statement can be made if we only talk about speed: change to resvg. Clearly speed is an issue, but it is not the only issue. Nowhere did I say switch to Inkscape. From earlier comments in this task, speed is a significant consideration but not the only one. Somebody made a remark about weighting features.

My statement pointed to three rendering issues: BIDI, markers, and systemLanguage. To me, the render must support those features: no support means it is not a viable replacement.

Commons is a multilingual website, and choosing a renderer that cannot do BIDI implies dropping support of languages such as Arabic, Persian, and Hebrew.

Similarly, dropping support of systemLanguage would mean many i18n images would fail. They might even fail with unusual results (if systemLanguage is ignored, then the first clause would always be rendered). Diagrams that used to render in Deutsch might render text in some other language.

Librsvg used to do markers wrong, and there many complaints. Dropping markers completely would seem to reraise those issues. Directed graphs would lose their direction.

When resvg gets those features, then the choice can be viable. systemLanguage is easy to do. Markers are similar to use elements but need to compute a tangent. The only difficult feature is BIDI, but one could hope a library would already do most of it (e.g., Windows GDI does reordering).

From a social standpoint, I would expect resvg to add and fix features quickly. It may have a viable set of features and a Debian package next month.

As a parallel question, would it be acceptable to serve small SVG files? How small would the file have to be? A chemical structure SVG can be a few kilobytes that does not use any exotic SVG elements. Would a 20kB SVG be small enough to serve directly? There are some monster featured-picture SVG files that would be more efficiently served as bitmaps, and the File:Dojikko2.3.svg example was 18.3 MB at one point. Network bandwidth is a significant constraint. I can also see WMF saying no to directly served SVG on security grounds. The number might be different for mobile, too.

@Glrx

Hi, I'm the resvg author.

I don't think that you should switch to the resvg in a near future. It's stable (except API), well tested, but still under development.

On the other hand, I'm interested in implementing the features you mentioned in the first place.

Some notes:

resvg does not support marker but librsvg does.

Badly.

resvg does not support font-variant;

It does, actually. It's a pango bug, but I have not found the solution yet.

resvg does not support a font-list

It does.

resvg does not support letter-spacing; librsvg does.

No, it's not.

resvg does not handle overflow

It does.

Also, librsvg doesn't support x, y, dx, dy, rotate lists on text-based elements.

I would expect resvg to add and fix features quickly. It may have a viable set of features and a Debian package next month.

Sadly, I will be busy for the next few months, so a new release will be closer to the end of a year.

At the moment, resvg has a better support of implemented features than any other SVG library (see resvg test suite results).

Patrick87 added a comment.EditedJul 18 2018, 8:04 PM

Inkscape is not a rendering library but an image manipulation application that uses librsvg as its rendering library (at least on Fedora).

That's not true! Inkscape has it's own SVG renderer based on cairo. librsvg is only an (optional?) dependency handling generation of previews in the GTK+ file chooser but has no other function beyond that.

As Johannes mentioned there's a command line ("batch" mode) that converts SVG to PNG without requiring the GUI.

That said - while rendering is probably pretty advanced (supporting mesh gradients and other advanced features you'll hardly find anywhere else) - speed can be an issue, especially if filters are involved and large renderings are requested. (Inkscape's PNG output is not optimized for speed but prefers rendering quality).

Glrx added a comment.Jul 18 2018, 8:28 PM

Thanks for developing the code, and thanks for your comments and advice.

I used the support table

https://razrfalcon.github.io/resvg-test-suite/svg-support-table.html

and it says things like letter-spacing, font-variant, font lists, and overflow are not supported. It has overflow supported for some particular items, but there's a red mark for overflow in general. I'm very happy you provided the support list, but my inspection of it was cursory. I'd expect the table entries to improve over time, and yes, if you use a library with issues, then you inherit those issues and hope the library gets fixed.

We would like to see SVG rendering improve, and resvg is a tantalizing alternative.

Librsvg has problems, but we are living with them. It would be nice to have better rendering, but I don't know if the servers have the margin for a slower but better renderer. Batik takes 50% longer; Inkscape 75% longer, and ImageMagick 100% longer according to some 2009 tests. I don't know how much those numbers hurt. I'd like to see tb text work, but is that worth a 50% hit? My guess is the answer is no; if it had been worth it, then we would have switched a long time ago. Resvg may offer improvements without the hit.

Yes, the overflow attribute is marked as unsupported, but only because its too generic. resvg simply does not support all elements that can have overflow yet.

@Patrick87: Ah, I did not know that. Thank you for correcting my wrong statement.

tstarling moved this task from Inbox to Backlog on the TechCom-RFC board.Jul 18 2018, 8:53 PM
daniel added a subscriber: daniel.EditedSat, Jul 21, 10:22 PM

To quote what @cscott said four years ago on this ticket:

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.

Note that this is a security concern for server side rendering.

This comment was removed by daniel.

Batik takes 50% longer; Inkscape 75% longer, and ImageMagick 100% longer according to some 2009 tests.

I'm gonna go out on a limb here and suggest that maybe performance benchmarks from 2009 are not relevant in 2018, there have likely been many software and hardware changes since then.

@Krenair The software is indeed changed but in a bad way. At the moment Inkscape and Batik are extremely slow. At least according to my own benchmarks. Batik can be faster if we use it as a daemon, because JVM startup is very slow, but I'm not sure how much memory it will consume in that way.

Besides, benchmarking an SVG is pretty hard. Everything boils down to the specific SVG file itself and to list of supported features of the rendering library. For example, if we have a file with Gaussian blur, QtSvg will always be faster, because it simply skips it. Same goes for other high-level and expensive operations. For example, Batik doesn’t support anti-aliasing during clipPath rendering, which makes it faster, but incorrect. Also, Batik doesn't support test shaping, which is also incorrect.

At the moment, librsvg has no real competitor performance wise.

I refered to a different benchmark:
RazrFalcon updates the benchmark more often than Wikimedia updates librsvg (!), therefore I can't see your Problem with: https://github.com/RazrFalcon/resvg/#performance
RazrFalcon might has optimised resvg for his own hardware, and therefore benchmark might be a little different on Wikimedia servers.

Programrender timeTests passed
resvg150 s (best)221
rsvg 2.42.2242 s202 (worst)
Inkscape 0.92.21610 s257
Batik 1.93686 s254

The benchmark uses librsvg 2.42.2, wikimedia uses 2.40.16 (2.40.2 for SVG Checker), and the current version is 2.43.2.

As @Glrx pointet out we need systemLanguage which can't be handled with resvg, therefore as said by @RazrFalcon we should not change now to resvg, therfore should stay with librsvg.


But I would like to be able to set a flag (f.e. on the descriptionpage) to change some specific SVGs to be rendered by inkscape:


Checking https://commons.wikimedia.org/wiki/Librsvg_bugs (Most common Bugs are reported here)


Checking https://commons.wikimedia.org/wiki/Category:Pictures_showing_a_librsvg_bug_(unsolved) (Most difficult SVG to make a workaround)


Bugs checked by Commons SVG Checker


Because inkscape is based on librsvg it is most likely that there were will hardly any (maybe none) new not reported bugs. (The performance would not be a problem if it is possible to set a flag to specific SVGs to be rendered with Inkscape, but all other will be rendered by librsvg.)

5 Most important bugs: (all of them would be fixed by Inkscape)

  1. T11420 as already pointed out by @Glrx
  2. T36947 maybe most reported bug on Commons:Graphics_village_pump
  3. T43424 maybe best reported bug on helppages on commons Help on de, Help on commons, Category:Images_with_SVG_1.2_features, User:JoKalliauer/RepairFlowRoot
  4. T55899 maybe most common bug on Commons I repaired more than 250files (but that would be fixed with the update anyway)
  5. T20463 most bugs in Category:Pictures_showing_a_librsvg_bug_(unsolved)
RazrFalcon added a comment.EditedSun, Jul 22, 10:43 AM

@JoKalliauer

RazrFalcon might has optimised resvg for his own hardware

There are no hardware-specific optimizations.

Because inkscape is based on librsvg

It's not. Inkscape has it's own rendering backend.

Dzahn removed a subscriber: Dzahn.Mon, Aug 6, 2:25 PM