In my experience, literally every SVG rendering engine in existence is less problematic than rsvg.

The problem I can foresee is that this would further discourage our vector artists from NOT converting text to path because you can't require our readers to have the same typefaces installed on their OS as those specified in the SVG file. Even if they do have the required typefaces, different SVG renderers have different interpretations of kerning (glyph horizontal spacing). I want consistency of text appearance while still maintaining text to be selectable and searchable, and funny though this is what PDF format is capable of while keeping the general file size smaller than the same SVG image which has all its text converted to path, because most vector editors like Inkscape and Adobe Illustrator do not share path object of same glyph of same font during conversion. I use the free RSVG-Convert tool (http://opensourcepack.blogspot.hk/2012/06/rsvg-convert-svg-image-conversion-tool.html) to create PDF version of my SVG. The resultant PDF while is not completely but reasonably consistent to my SVG source.

Unfortunately Wikimedia uses a worse rasterizer of PDF which results in low quality JPG version of each PDF page, but I guess this is not a great deal if the PDF is meant to be open separately and no SVG animation/interactive function is required.

@Sameboat consistency of text positioning is indeed a *very hard problem*.

It gets both harder, and easier, when you remember that we're mostly building materials for a multilingual system of reference works, and need to make text labels localizable.

This has several implications:

• text strings will often be different from the text the artist worked with
• text strings may require fonts the artist never heard of
• text strings may be much longer or much shorter than the texts from the language the initial artists worked with

Proper positioning of bounding boxes and alignment on text elements is key to producing artwork with enough flexibility.

Do you have some examples of SVG files in use that require exact positioning of text that can't be localized or have fonts change a little from under it? (We can always load fonts along with the rendering, as we can with the web page, though as you note there may still be slight variations in rendering.) I'd like to get a better idea what "other" uses of text output are going on that don't fit the model of labels on a diagram, in which case we should make sure we deal with those well too.

@brion High quality SVG images by User:Kelvinsong made from scratch. He usually duplicates all texts to the higher layer and set it to opacity=0 then path-izes the visible text. I respect him, but I can sincerely say there is absolutely no reason to do that except that Wikimedia and many readers do not have his type of preference, Neue Frutiger, installed which isn't legally free to my knowledge.

https://commons.wikimedia.org/wiki/User:Kelvinsong
https://commons.wikimedia.org/wiki/File:Hurricane-en.svg
https://www.linotype.com/610683/neue-frutiger-family.html

@Sameboat thanks!

Leaving aside the font issue, just looking at metrics and flexibility in the case of changing text...

Many such as https://commons.wikimedia.org/wiki/File:West_Antarctic_ice_sheet.svg and https://commons.wikimedia.org/wiki/File:Ganymede_diagram.svg look like good candidates for regular text rendering and easy localizability; if the text elements were plain text, and changed to be sized/aligned properly with available space for longer texts, it should work fairly simply to swap out just the text elements while keeping the entire structure intact.

https://commons.wikimedia.org/wiki/File:Centrosome_Cycle.svg or https://commons.wikimedia.org/wiki/File:Plant_cell_types.svg are harder as they pack a lot more text in, including long sentences that wrap over multiple lines... there's very little room for additional text if font metrics end up a little different or if a translation is longer. These would need to either localized by re-arranging items on the text layer manually (which is possible using the switch mechanism) or through some sort of automatic style marker to force text to fit at rendering time (I have to look up if that's actually possible!) Alternately they could be rearranged with more buffer space to begin with.

Some like https://commons.wikimedia.org/wiki/File:Hurricane-fr.svg and https://commons.wikimedia.org/wiki/File:Hurricane-es.svg also include some visual effects that depend on the size of some of the text, which may complicate things.

@brion Packed text passage could be solved in SVG 2.0 with the new text properties "inline-size" https://www.w3.org/TR/SVG2/text.html#InlineSize and "shape-inside" https://www.w3.org/TR/SVG2/text.html#TextShapeInside, if SVG 2 is implemented into librsvg but I am very pessimistic with that. Anyway it's true that localization usually requires the active vector artist (usually the original author) to rework the image for minimal collision of elements after the image is translated by another contributor with little knowledge of SVG.

Comparison image for illustrating the text handling of different SVG libraries:
https://commons.wikimedia.org/wiki/File:Comparison_raw_text_converted_path.svg

Is any browser capable of showing png but not capable of showing svg out there left?

Not that we intend to support, at least. The WMF HTTPS requirements also prevent most of those browsers from connecting at all.

In T134410#8433503, @Vollbracht wrote:

Is any browser capable of showing png but not capable of showing svg out there left?

If there is such a browser, I would not bother supporting it.

• https://caniuse.com/?search=SVG

Shows SVG 1.1 support for all listed browsers.

The WMF SVG converter is SVG 1.1 (with bugs).

The font issue is more problematic. Commons does not allow SVG files to use CSS web fonts, so that avenue is foreclosed. (Perhaps we could allow web fonts that point to Commons.)

The simple route out of the font issue is to use CSS fallback fonts (e.g., sans-serif). I suspect that all HTML 5 browsers have CSS fallback font support, and that would carry over to their SVG implementations.

Consequently, I would close this topic as resolved.

Yes! Please!

Shall we close this, then?