In T213139#4868252, @Niharika wrote:

Here's a screenshot of what I see on the two sites:

SVG Translate (1292px)	Commons (1524px)

Notice the legend and X-axis character and word spacing differences.

Just a note for possible workarounds:

@Aklapper
As far as I understand @Watchduck on Commons: They want to extract the PNG and overwrite the SVG with the extracted PNG, so that in the file-history is a mixture of file-types. (not any more a svg).

@Jonteemil : Regardin JPEG-Preview of the *jpg: I just compared full-size-preview with 120px-preview (not the raw file), thanks that is strange and might be a different issue.

I purged the first two files useing ?action=purge, and they rendered quite differently (one imho worse, one imho better, but mostly different), and in both of them even the full-size-preview was imho before purging was awefull (not as described in the bug-descripiton).

Is using an :w:en:AppImage, e.g. as provided by Inkscape, a possible solution? That would make the renderer-version independent on the Debian-version or any libary-version. As far as I know AppImages (single-executable-file, distribution-independend) are portable and can be run on any Linux-system without any prerequisites, without installing (without root-permission).

I missunderstood @Watchduck , so I edited my answer:

In T106240#7109062, @Aklapper wrote:

This is fixed in librsvg version 2.47.3 and later librsvg versions.

Quoting the librsvg-developer from https://gitlab.gnome.org/GNOME/librsvg/-/issues/736#note_1119478

Hello, Keep CoC and Phabricator etiquette in mind. Thank you.

In the Wikiversum: New anonymous newbies have the ability to change content without understanding Wikipedia, so many experienced users in the Commuinty are used to speak quite straight(Not something I like.), otherwise the Wiki get crowded by wrong edits. I think that's a reason why many Newbies find Wikipedia-Discussions generally quite harsh, also we maybe have similare rules in :w:en:Wikipedia:Etiquette and :w:en:Wikipedia:No_personal_attacks. So I would not overinterpret the tone of Glrx (Commons-Community-member).

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

Thank's for Joining!

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.

FYI: related librsvg-issues:

• librsvg#735 RFC: meta-issue for localized SVGs make it easy for Wikimedia to have localized SVG
• librsvg#356 Provide a way to specify the user's preferred languages specify langtags
• librsvg#357 Take weights into account when matching systemLanguage if allowReorder=yes

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 .

@Glrx sorry I missed it earlier.

In T282740#7091212, @AntiCompositeNumber wrote:

Organizing by category is better in this situation, because Wikimedia-SVG-rendering has been used as a bit of a catchall for SVG-related tasks. Some of what you have categorized as "MediaWiki" would actually fall under Thumbor, while others fall under MediaWiki-File-management or other MediaWiki components. I don't know how useful separating these two would be on this board however, and they're already identified by tags.

librsvg would like to make it Wikimedia easy to have localized SVGs. (ref)

In https://gitlab.com/inkscape/inbox/-/issues/1913#note_297127723 , Tavmjong Bah @Tavmjong wrote:

This, BTW, is an outdated way to get small caps. Most modern fonts will support small caps in the Unicode small caps block. These characters can be accessed using the Features tab of the Text and Font dialog.

In T193942#6543745, @AntiCompositeNumber wrote:

Still needs to be reported further upstream to Cairo.

According to wikimedia-svg-rendering-table only 2 librsvg-tasks of ~48 librsvg-tasks is set to stalled, so this means the remaining 46 librsvg-tasks should set according to T282740 also to stalled?

In T282973#7091071, @Reedy wrote:

Wikimedia probably aren't going to start "maintaining" abandoned upstream project(s), especially when there are newer versions or viable alternatives.

@Glrx: Sorry I do not understand language-interaction between MediaWiki and librsvg. Is it correct it is reported upstream at:

• https://gitlab.gnome.org/GNOME/librsvg/-/issues/131
• https://gitlab.gnome.org/GNOME/librsvg/-/issues/256

In T282951#7090852, @Aklapper wrote:

MediaWiki wiki syntax is too unclear and ambiguous (does ''''' mean <i><b> or <b><i> in HTML?)

'''''test''''' resulted in a test in <i><b>test</b></i> and don't care if it would be the other way around.

In T218828#7089636, @Dzahn wrote:

You are the author, so I think if you are satisfied with the explanation, then yes it can be closed.

In T282888#7088960, @Nintendofan885 wrote:

this is because the 'w' prefix links to the respective Wikipedia for the language of a wiki and Commons has it's default language set to English so it's intended.

So I think this issue can be closed as resolved?

In T36947#7076752, @Arthur2e5 wrote:

At least the 2.51.1 result makes more sense and works in non-extreme scales...

Upstream at https://people.gnome.org/~federico/blog/do-not-use-librsvg-2.40.x.html (by the main librsvg-developer)

The issue was that I assumed that https://apt-browser.toolforge.org/stretch-wikimedia/component/thumbor/ would show the current version, however it seems we are currently using librsvg 2.40.21.

In T276684#7087582, @Aklapper wrote:

Question where?

The image looks identical since a while.

@Aklapper : The question was not if it was fixed upstream (the title might be missleading), the question was "Was there currently an librsvg-update on thumbor?"

In T55899#1463965, @waldyrious wrote:

How does this relate to T8250?

In T55899#1463965, @waldyrious wrote:

How does this relate to T8250?

The issue has a regression before librsvg 2.51 for https://commons.wikimedia.org/wiki/File:T142908.svg , imho duplicate of T36947

The issue seems to be resolved:
https://upload.wikimedia.org/wikipedia/commons/thumb/archive/b/b2/20210509151853%21Inverse_Verwerfung.svg/217px-Inverse_Verwerfung.svg.png

imho a duplicate of T36947, which is not a subtask of Updating librsvg, but maybe a subtask of reevaluating svg-render T40010

So for dummies: (default language) in Commons should not return systemLanguage="en", but the one without any systemLanguage. So if Mediawiki sets e.g. export LANG=InvalidLanguageForFallbackLanguage for (default language) the issue would be fixed, so thats a MediaWiki-issue not a librsvg-issue?