Page MenuHomePhabricator

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: [DO NOT USE] 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
Resolvedbd808
ResolvedJoe
DeclinedArielGlenn
ResolvedArielGlenn
Resolvedori
DeclinedNone
ResolvedMoritzMuehlenhoff

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.EditedJul 21 2018, 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.EditedJul 22 2018, 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.Aug 6 2018, 2:25 PM
Rxy added a subscriber: Rxy.Oct 17 2018, 2:25 AM
mxn added a subscriber: mxn.Nov 10 2018, 10:09 PM

@Glrx Hello again.

Since the last comment, resvg gained two more updates and supports almost everything now, except BIDI. You can see a list of all unsorted features here. And SVG support table here.
The main focus of the next release will be on textPath, direction, unicode-bidi and writing-mode.

I'm interested in any feedback regarding the supported features. Maybe something should be prioritized and maybe something important is missing.

Glrx added a comment.Jan 4 2019, 7:08 PM

Thank you for the progress update. I'm happy to hear the good news.

I just looked through the tables.

resvg says Chrome only supports 56% of switch. I believe Chrome fixed all its switch-related issues in October (eg, space-separated instead of comma separated langtag list; subclass test was reversed; case sensitive comparison). I viewed a file the other day which made me believe that Chrome also does the SMIL allowReorder clause selection (Firefox does that).

In looking at the support tables, my primary concern is with entries that are unsupported in the resvg column but supported by librsvg. That's where Commons will see differences. If there is such a disparity, the next question is how frequent will the disparity appear. My experience is usually simple diagrams; they often do not use filters. More involved art may use many filters. Another question is how much damage the disparity does. If the image is still presentable, then the disparity would be minor. Failing to blur an object is minor; failing to paint the object would be major.

Fontlist is important. Many Commons users are confused and unhappy with font support, so there has been a push to use font lists such as "Neue Frutiger 55, sans-serif". A font list can give a user his favorite commercial font on his local machine and let Commons render a reasonable facsimile. In many situations, Commons will not have the first font in the list.

Embedded fonts are something that Commons discourages. We don't want licensed fonts embedded in otherwise free files. So it's not something high on my priority list. Commons will not want external font definitions chased even if those fonts are allegedly free. CSS font chasing should be disabled.

Nested sub- and superscripts are used, but not often. Many diagrams have typeset math formulas, so there will be formulas such as the normal distribution's e to the x squared. A modest priority.

BIDI priority is high, but librsvg bugs have probably kept the issues down. Most files on Commons that set direction to rtl will have improper SVG because librsvg paints the text the wrong direction; it's OK if those files do not render reasonably; they need to be fixed. I will tolerate "broken" images that are really improper SVG. Most librsvg files will stuff RTL characters into an LTR string. If the string is RTL dominant, it usually works, but put some LTR and neutral characters into the string, and the display may get strange. Any good BIDI implementation would be welcome. BTW, the SVG specification is ambiguous about text chunk placement.

Other issues appear to be desired features rather than necessities. Librsvg does not do textPath, and lack of textPath is probably the second most common reason for converting characters to curves. I want textPath, but it is not so valuable that I'm willing to tolerate a lot of broken images on Commons.

For vertical text, librsvg is a mess, so there are very few instances of vertical text on Commons. Most Commons diagrams will just convert the characters to curves. So vertical text is not a high priority now. Having it will allow us to simplify existing images and do new images correctly. A common workaround is to rotate Chinese strings 90 degrees, but I suspect that annoys Chinese readers.

Attribute selectors are not supported by librsvg, and some users have been frustrated by their absence. It is not important now, but there is some interest. Similarly, lang() pseudo class selectors could be useful. Very low priority.

Any SVG feature that is not supported in Chrome and Firefox is probably irrelevant to Commons.

Thanks for a detailed answer!

I believe Chrome fixed all its switch-related issues in October

I'm using Chromium build that comes with puppeteer.js. Maybe it's a bit outdated.

In looking at the support tables, my primary concern is with entries that are unsupported in the resvg column but supported by librsvg

librsvg supports more filter variants (like feColorMatrix), but the filter support, in general, isn't that good, as you can see. Also, librsvg supports enable-background which is used by filters, and resvg don't yet. Not sure if there is anything else.

Fontlist is important.

It's supported. It works on Qt backend but fails in cairo. It's a minor bug.

Embedded fonts are something that Commons discourages.

This part I really don't want to implement, because it's pretty big and I'm not sure if someone actually uses it.

Nested sub- and superscripts are used, but not often.

It's doable. Just left it for later.

BIDI priority is high, but librsvg bugs have probably kept the issues down.

The main problem with BIDI is that no one really supports it. So it's hard to tell how it should be rendered in the first place. Like glyph-orientation-* is only supported by batik. But on the other hand, it doesn't support text kerning. Which makes it pretty useless. Also, Firefox doesn't support baseline-shift, letter-spacing and word-spacing completely.

The comparison table is a bit misleading, since I mark a test as passed if resvg renders it correctly with both backends. And there are a lot of text-related issues that work in the Qt backend and fails in the cairo one.

lack of textPath is probably the second most common reason for converting characters to curves

I didn't look into it so I have no idea how hard it will be to implement, but I don't think that there will be any major problems.

For vertical text, librsvg is a mess

It uses pango's own implementation, kinda, and the problem with that is that Qt doesn't support vertical text at all. So the vertical layout should be implemented manually. And I don't think that simply placing glyphs vertically one after another is a good idea. The only explanation I could find is in CSS Writing Modes.

Attribute selectors

CSS support is partially out of scope. Currently, I'm using my own CSS parser which is extremely primitive. So at first, someone should write it. And not only a parser (which is already exists), but also a resolver.

Any SVG feature that is not supported in Chrome and Firefox is probably irrelevant to Commons.

The one thing I learned after writing resvg is that SVG support in browsers isn't that good. Anyway, almost everything from static SVG subset is already implemented. Just need to polish it a bit.

Joe added a subscriber: Gilles.Apr 11 2019, 6:01 AM

Wikimedia nowadays is using https://github.com/thumbor/thumbor to render all thumbnails, including SVGs. I'm not sure how resvg would fit into it, as I'm completely ignorant about the details of how thumbor uses librsvg. @Gilles do you have any idea of how easy it would be to swap usage between the two libraries?

It's very straightforward to switch to something else, here's the entire logic for SVG processing at the moment: https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/thumbor-plugins/+/refs/heads/master/wikimedia_thumbor/engine/svg/svg.py

I can't find the man page for the resvg command-line tool. What it needs to support is rendering to a specific width and the ability to set the language you want rendered (for multilingual SVGs).

I can't find the man page for the resvg command-line tool. What it needs to support is rendering to a specific width and the ability to set the language you want rendered (for multilingual SVGs).

See https://manpages.debian.org/unstable/resvg/rendersvg.1.en.html

It has everything we need, then. If you feel like backporting this to Stretch, I can write the Thumbor engine and tests for it. Then we can test it easily via config override on a specific Thumbor server.

It has everything we need, then. If you feel like backporting this to Stretch, I can write the Thumbor engine and tests for it. Then we can test it easily via config override on a specific Thumbor server.

Given https://phabricator.wikimedia.org/T40010#4432284 I think the most promising next step is to wait a few more months and migrate thumbor to the buster and the rust-based new librsvg, I mostly mentioned the availability in Debian as I saw it arriving in the Debian archive and remembered this task.

Given https://phabricator.wikimedia.org/T40010#4432284 I think the most promising next step is to wait a few more months and migrate thumbor to the buster and the rust-based new librsvg

This is pretty outdated. The up-to-date comparison table can be found here.

Jc86035 added a comment.EditedApr 11 2019, 10:41 AM

Just noting, if resvg doesn't support non-UTF-8 files or files with no size (per the table) then it'll probably break a lot of existing files unless they're all fixed before it's implemented (if ever). UTF-8 didn't become the most popular encoding until around 2009 (per enwiki), and there are still a lot of older SVGs lying around.

@Jc86035 SVG without a specified size is an undefined behavior. There are no tests for this yet, so I'm not sure how good the librsvg and other implementations are.

As for UTF-8, yes, it's not supported yet and not planned. Not sure what I can do here.

Jc86035 added a comment.EditedApr 11 2019, 10:54 AM

Just for clarification:

  • Does resvg accept viewBox="0 0 500 500" without other dimension attributes? librsvg doesn't recognize this (example) and reads it as 512 × 512.
  • Does resvg accept SVGs without an XML header (I don't remember any specific examples at the moment) or without any encoding specified (example)? Both work with librsvg.

Does resvg accept viewBox="0 0 500 500" without other dimension attributes?

Yes.

Does resvg accept SVGs without an XML header

Yes.

SVG without a size is something like:

<svg xmlns="http://www.w3.org/2000/svg">
    <rect width="100%" height="100%"/>
</svg>

You have to specify a viewport size in this case, which is not supported yet.
librsvg will render a 1x1px image in this case.

Jc86035 added a comment.EditedApr 11 2019, 11:10 AM

Oh, okay. If files are only broken if they contain invalid bytes (not just encoding="iso-8859-1") then actual thumbnail errors will probably be a little less rare.

Would this file break? It contains "Ü", but the character is in the <title> element.

Would this file break? It contains "Ü", but the character is in the <title> element.

This file has a UTF-8 encoding, despite the encoding="iso-8859-1" attribute. So it will be rendered correctly.

resvg tries to load a file as UTF-8 string. It doesn't care about the XML encoding attribute.

It isn't necessarily one or the other. It's very conceivable to try to render a file first with resvg, and if the file can't be processed (command errors), try to render it with librsvg.

Does resvg accept viewBox="0 0 500 500" without other dimension attributes? librsvg doesn't recognize this (example) and reads it as 512 × 512.

It might be better to file specific tasks instead of bringing up several librsvg issues in this very task. For this very issue, the output in more recent librsvg is:

@Aklapper resvg has a prebuilt viewer too. So you can test it right away.

Kghbln added a subscriber: Kghbln.Apr 11 2019, 8:53 PM
Kghbln removed a subscriber: Kghbln.Apr 11 2019, 9:02 PM