Hello @JoKalliauer and thanks for your proposal!
Unfortunately, we cannot add any session in the main track at that point. However, feel free to book a 55min slot in one of the hacking rooms! You can look at the schedule, choose the slot that suits you best, and directly add it in the wikitable.
If you need any help with that, let me know.

Thanks for the approval of the discussion.
I took Saturday 15:00 UTC, see https://www.mediawiki.org/wiki/Special:Diff/4586871#Saturday,_May_22nd .

Perfect!

@JoKalliauer

Thanks for volunteering to do this topic and expanding the audience.

You are showing a lot of detail, but you are not stating your position or advice. Do you want to take such a position? Do not bury your good advice with mountainous details. You are one of the most experienced editors at working around librsvg rendering errors, so your viewpoint and advice are valuable.

You've signaled important topics at T282740 and set priorities.

For the audience, you should list the choices:

1. librsvg 2.50 (WMF currently uses 2.40)
2. resvg
3. inkscape
4. batik

The details do not mention the frustration that graphic artists have had with SVG on Commons. You have a great understanding of those problems. You know about the 600 workaround files How many artists have given up on creating diagrams or converted text to curves due to small font positioning errors or no support for textPath? That creates bloated files and frustrates people who want to translate diagrams to other languages.

So the impact on the graphic artists is important in the evaluation.

What the ordinary users will see is also important.

For me, the WMF renderer must not have small font positioning problem. Too many graphic artists have been bitten by that bug. That means librsvg is unacceptable until that bug is fixed.

The textPath element is also a significant problem but not as prevalent as the small font positioning problem. There are many maps on Commons, and many of those maps have text converted to curves. It would be good if the WMF renderer had this capability. I lean toward textPath being a requirement. That means librsvg should add the feature.

There are many multilingual files on Commons, so the WMF renderer must support the systemLanguage attribute. Currently, MediaWiki transmits the language preference through the Unix LANG environment variable. That method works with unhyphenated IETF language tags such as de, en, and es, but the method does not work with hyphenated langtags such as sr-Cyrl or zh-Hans. MediaWiki software needs to be upgraded. The language preference should be passed in a command line argument as is done by resvg and batik. I would make this a requirement, so librsvg and inkscape need updates.

Rasterization speed is an issue, and that probably knocks batik out of contention.

There are other. less prevalent, rendering issues, but they still cause grief to graphic artists. Commons should support most of SVG 1.1. More coverage is better.

You are showing a lot of detail, but you are not stating your position or advice. Do you want to take such a position?

Yes I wanted, but the recommended 150words were too short. ;-)
Based on @Gilles comment (to maybe use two renderer), I already took position: "My personal recommendation would be resvg, and a flag for changing the renderer to librsvg." resvg is faster (maybe because it has a faster backend: skia instead of cairo) and also supports the most SVG1.1-features (maybe with the exception of Chrome/Firefox) . I would like rust-librsvg 2.50 as alternative (per flag) to keep the regressions-bugs low. However there are negligible C-librsvg-2.40-features that are not supported by others, so the regression-bugs are imho not something to worry. Actually if we worry about regression-bugs, I would worry most about rust-librsvg2.50/Inkscape: not supporing hypened langtags.

Why not rust-librsvg2.50: Rust-librsvg-2.50 has still no textPath, bad font-kerning , does not support hyphened langtages and does not render pattern on small scales.

Why not Inkscape: When I was a svg-newbie, seeing all the C-librsvg-2.40-bugs, I thought Wikimedia should use Inkscape instead of librsvg. However I declared my position in the inkscape-project that I see Inkscape as an editor not as an render, because it supports inofficial Inkscape-features. If we would now support front-edge-inkscape-features we might end up having inkscape-files that maybe no-one supports any more in 20 years (e.g. the SVG1.2-flowRoot will imho die out). Even the inkscape-maintainer said: "Although it sounds like resvg is probably what you need."

Why not batik: It is slower than others, and it often crashes which is imho worse than a incomplete/incorrect rendering (crashing also more difficult to make workarounds, because you don't know why it fails). Also I included batik in the benchmark, I would exclude it from taking into consideration (at least as long as I do not hear any arguments flavouring batik) .

For the audience, you should list the choices:

1. librsvg 2.50 (WMF currently uses 2.40)
2. resvg
3. inkscape
4. batik

Yes that's what I'm planing (and focussed in my SVG benchmark), however I will skip batik because no-one argumented for it. However there exists far more renderer/wrapper, only Chrome/Firefox are realistic alternatives (at least in terms of supported features).

For me, the WMF renderer must not have small font positioning problem. Too many graphic artists have been bitten by that bug.

With the exception of textPath this bug (bad font-kerining) is for Commons imho the most important bug in C-librsvg-2.40 (which is 4years old), however it imho got even slightly worse (!) in rust-librsvg-2.50. Funnily librsvg-developer saw this issue, I reported, last week for the first time occurring on Linux. (font-rendering is imho OS-dependent)

That means librsvg is unacceptable until that bug [i.e. font-kerining] is fixed.

Your statement means that the current situation is unacceptable. I think this shows the importance of this session, because there seems to be a gap between the expectations of the SVG-community and WMF-developers, which should be closed.

The textPath element is also a significant problem but not as prevalent as the small font positioning problem. There are many maps on Commons, and many of those maps have text converted to curves. It would be good if the WMF renderer had this capability. I lean toward textPath being a requirement. That means librsvg should add the feature.

That's the most common librsvg-bug in Category:Featured_pictures_on_Wikimedia_Commons_-_vector

There are many multilingual files on Commons, so the WMF renderer must support the systemLanguage attribute. Currently, MediaWiki transmits the language preference through the Unix LANG environment variable. That method works with unhyphenated IETF language tags such as de, en, and es, but the method does not work with hyphenated langtags such as sr-Cyrl or zh-Hans. MediaWiki software needs to be upgraded. The language preference should be passed in a command line argument as is done by resvg and batik. I would make this a requirement, so librsvg and inkscape need updates.

In percentage only view svgs are multilingual, however the most important svgs are often multilingual. Multilingual files are so important for the Community, that even WMF, themselfs, developed svgtranlsate-tool (2017 Wishlist survey) .
Most multilangues images imho contain only unhyphenated language-tags, but still, not supporting hyphenated language-tags such as en-US is imho an severe regression issue.

For those who do not understand the issue, maybe take a look at T 265549#7097492 for examples.

Rasterization speed is an issue, and that probably knocks batik out of contention.

According to my estimation : Every day on average are about 500 new svg-files uploaded which might have approximately 2 versions, each rendered in maybe 15 sizes, leading to ~20000pngs per day. If the average rendering time is below 4s then it could (on average) be rendered by a single cpu. Even batik will be (slightly) below 4s (for an average commons-image). I don't know how realistic my estimation is. Maybe also fluctuations should be taken in to account.

You are one of the most experienced editors at working around librsvg rendering errors, so your viewpoint and advice are valuable.

Thanks for that comment! I guess I fixed about 75% of the fixed svg-files on commons, so I might know C-librsvg-2.40-bugs best, and know how common they are on commons. I repair them e.g. with https://svgworkaroundbot.toolforge.org/ (provided by me) which uses e.g. svgcleaner (developed by the resvg-developer) and I use Inkscape for drawing images. So I kind of have different experience with all of them, so I try to not be biased.

Everyone has different experience

• @Glrx: I don't know anyone on Commons (not talking about developers) has so detailed knowledge about the specs.
• @Sarang: I don't know anyone who can draw so efficiently (less bytes) SVGs.
• @Cmglee: I don't know anyone knowing animated SVGs that well.

So I hope that this Discussion on Saturday aswell as on T40010 can merge all those different experience together, that WMF has a clear answer that the community wants, which can be implemented.

There are other. less prevalent, rendering issues, but they still cause grief to graphic artists. Commons should support most of SVG 1.1. More coverage is better.

This would imho mean: resvg should be the choice. [side-note: Some svg-features such as animations (png) or external content (blocked) are not relevant for Wikimedia.]

@JoKalliauer

I agree with you.

"[T]he current situation is unacceptable" is wonderfully clear. We should not be wasting time working around the many bugs in librsvg 2.40 nor should we continue to waste time working around the bugs that remain in librsvg 2.50.

So given the current constraints and current offerings, the reasonable choice is resvg.

Although librsvg can be updated later, it currently does not meet MW's needs.

Great news is your GNOME #730. Federico's comment states:

It looks like librsvg has to do text rendering in device-space. Currently it is done in user-space. For example, the last line in the example above has a font-size of 2.5 and a 8:1 scaling transform. The first line is a font-size of 20 and a 1:1 transform.

That shows that GNOME finally understands the problem and therefore has a chance to fix it. IIRC, they were claiming it was an upstream-to-GNOME graphics library bug.

For multilingual SVG with hyphenated langtags, the Chinese Wikipedia community is short changed. Translations for zh-Hans and zh-Hant are often added to multilingual SVG files, but only one of them will display currently. I wonder if that holds up development on the zh.Wiki. If a zh.Wiki user selects mainland China simplified script, then that user should be served zh-Hans SVG rather than zh-Hant SVG. If the Chinese user selects traditional Chinese, then he sould get zh-Hant. That would make sense. A similar issue exists on the sr.Wiki: if the Serbian user selects Cyrillic script, then he should get sr-Cyrl SVG rather than sr-Latn SVG. Same issue on the ku.Wiki. T283295.

Looking at a zh.Wiki page using different scripts shows that only zh is selected although the image has zh-Hans and zh-Hant.

• https://zh.wikipedia.org/wiki/%E7%94%B5%E7%A6%BB%E8%83%BD
  • src="//upload.wikimedia.org/wikipedia/commons/thumb/1/1d/First_Ionization_Energy.svg/langzh-400px-First_Ionization_Energy.svg.png"
• https://zh.wikipedia.org/zh-cn/%E7%94%B5%E7%A6%BB%E8%83%BD
  • src="//upload.wikimedia.org/wikipedia/commons/thumb/1/1d/First_Ionization_Energy.svg/langzh-400px-First_Ionization_Energy.svg.png"
• https://zh.wikipedia.org/zh-tw/%E7%94%B5%E7%A6%BB%E8%83%BD
  • src="//upload.wikimedia.org/wikipedia/commons/thumb/1/1d/First_Ionization_Energy.svg/langzh-400px-First_Ionization_Energy.svg.png"

I have questions about long term support for resvg, but those are moderated by potential improvements to librsvg and the possibility of serving SVG directly.

@Gilles could offer much better advice on SVG conversion times and their impact on the image scalers. I'd also worry about SVG PNGs aging out of the cache. IIRC, somebody said that there are SVG rasterizations requests about every second.

Thank's for Joining!

I try to summarize:

resposibilty
https://www.mediawiki.org/wiki/User:GDubuc_(WMF) (@Gilles) is responsible for Thumbor

2.50
Glrx: We cannot use 2.50. It will break stuff that works now.

versions
List of versions shipped in Debian:
https://packages.debian.org/search?keywords=librsvg2&searchon=names
and
https://packages.debian.org/search?keywords=resvg&searchon=names
("from stretch to buster", I think. Stretch = 2.40; Buster = 2.44)

render it by created tool
To me, it would make most sense to use the tool that created the svg to convert it to png. It's the author's experience that matters most - what they saw on their screen is what they should get on wiki*.
->Answer: That question already came up in T40010#6634884. That's not possible because too many tools, and some are proprietary and others can't render (gnuplot). It might be possible for inkscape, however this inkscape-version would be way old. However it is a question if we want inkscape-files (or just svg-files), see also T260286 where they are talking about depreciating gimp-files.

broken svg
After a recent update of the converter some of my files were broken (on a new upload) and I had no idea why and I have no means of fixing the files.
-->Answer: Most likely T276684, add {{Rsvg bug}} or ping @JoKalliauer

updating
The Problem of Updating:
("Upgrade Thumbor to Buster" =
https://phabricator.wikimedia.org/T216815
)
There is an (incomplete) dependency graph in
https://phabricator.wikimedia.org/T193352
showing which open tickets depend on 2.44 and on beyond

client-side-rendering (e.g for animated svg)
related tasks (not linking here)

• T 208578 SVG client side rendering for specific SVGs
• T 5593 [Epic] SVG client side rendering
• T 134410 Evaluate SVG rendering compatibility in browsers
• T 134408 Thumbnail-like rendering of localized SVGs for client-side rendering
• T 134455 Add experimental option for direct SVG output via srcset
• T 134407 Provide a way to reference fonts for client-side SVG rendering
• T 134482 Beta feature for opt-in client side SVG rendering
• T 49578 Score should output SV
• T 85838 Add a way to stop animated GIFs (annoying and epilepsy?)
• T 279238 illegal SVG patterns

My presentation can be found at https://commons.wikimedia.org/wiki/File:T283083_SVGRenderer.pdf

Thanks for participating in the Wikimedia Hackathon 2021! We hope you had a great time.

• If this session / event took place: Please change the task status to "resolved" via the Add Action... → Change Status dropdown.
  • If there are specific follow-up tasks from this session / event: Please create dedicated tasks and add another active project tag to those tasks, so others can find those tasks (as likely nobody in the future will look back at Wikimedia-Hackathon-2021 tasks when trying to find something they are interested in).
• In this session / event did not take place: Please set the task status to "declined".

Thank you,
your Hackathon venue housekeeping service