In T337199#9193502, @Bawolff wrote:

So i think related to the fix for T310235.

MediaWiki considers english the default, but maybe thumbor does not. So if something is set to english, mediawiki sees it equals the default and does not send the language along. Thumbor sees no language specified and assumes undefined.

Another complaint:

• https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&diff=prev&oldid=803253221#Clitoris_Anatomy_labels

Another user complaining about en failing:
*https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&diff=prev&oldid=803253221#Clitoris_Anatomy_labels

Another user running into this issue:

In T64986#9173170, @Timeshifter wrote:

I see lots of stuff between style tags in the SVG code. Is the problem this?:

<style>@import url(https://ourworldindata.org/fonts.css)</style>

That is something recently added by OWID.

Possible fix described at T337199 and T337139

When a URL does not specify lang, then set env to {'LC_ALL': 'en'} so rsvg-convert` knows the language should be English ("en").

@hnowlan
There is a related problem at T337199.

Code fix is would be related to T337139 by @hnowlan. Will comment there about the fix.

Another user has problems:

• https://commons.wikimedia.org/w/index.php?title=Help_talk:SVG&diff=prev&oldid=800280167

Gnome issue is

Reopen. Regression error.

To fix T344564 (font fallbacks), we need to upgrade to at least librsvg 2.48.5.

The font specification is done with

style="font-family:Lato, 'Helvetica Neue', Helvetica, Arial, 'Liberation Sans', sans-serif;font-size:18px;background-color:white;text-rendering:geometricPrecision;-webkit-font-smoothing:antialiased"
style="font-family:'Playfair Display', Georgia, 'Times New Roman', 'Liberation Serif', serif"

Another file is displayed incorrectly.

• https://commons.wikimedia.org/wiki/File:CoulombsLaw.svg

Another significant file on Commons that has the problem:

• https://commons.wikimedia.org/w/index.php?title=File:Standard_Model_of_Elementary_Particles.svg&lang=en

This issue was fixed in the 2.40 C-version of librsvg.

It looks like the file does not have a translation in the first 256kB.

This issue is a dup of T97233.

Renderer miscalculates the width of a text chunk.

The SVG file displays Portuguese:

• https://commons.wikimedia.org/w/index.php?title=File:Wikidata_nodes_in_white.svg&lang=pt

Reopen. Fix not complete.

In T335361#8836558, @hnowlan wrote:

For the short term we can hack around this rather than worrying about building a new version which will take time due to the differences in rust build environments in Debian.

Doing the following I see valid images being generated with Window (windowing system).svg:

for i in ar en de ru fr tr; do LC_ALL="$i" /usr/bin/rsvg-convert Window.svg -u -f png -w 800 > $i.png; done

This change should hopefully address this. Thanks for the report and the handy repro cases!

The current version of the file uses Unicode subscripted numbers AND a dy attribute:

This appears to be the same bug as T97233. That bug claims to be fixed in librsvg 2.50.2.

The problem is computing the width of an SVG "text chunk". If the text chunk consists of multiple XML nodes, then librsvg is using the width of the last node as the width of the entire text chunk. (librsvg is correctly tossing out the initial and final whitespace for the text element.)

In T65236#8919944, @JoKalliauer wrote:

@Glrx: According to T65236#8458679 the SVG-file has been fixed, could you provide an image that currently provides this issue and edit the task-description. (Otherwise I find it unclear&confusing.)

@Dzahn: Could you provide the fc-list as you already did in T280718#7025405 ?

In T337199#8887111, @IKhitron wrote:

I need to change the "File:Moscow metro map multilingual future draft.svg". If you still need it please fill free to revert to yesterday's version.

In T337139#8881950, @AntiCompositeNumber wrote:

The right thing to do is avoid locales entirely and pass the langtag through --accept-languages, but that must wait for next version of the operating system.

Packaging our own librsvg version or backporting from bullseye should be more possible than it was on stretch, since most (all?) of the rust buildchain dependency issues should be solved. I don't know if anyone's looked at the feasibility of doing that recently though.

In T337139#8880493, @hnowlan wrote:

Thanks for the report and the test cases. This change attempts to build valid locales to fix both of the issues. I am curious as to whether our approach of using these languages in Thumbor when we used LANG rather than LC_ALL would have ever worked for these language tags.

This bug affects a rather prominent SVG:

In T336917#8878586, @Samwilson wrote:

IIRC, SVG Translate has defined the svg prefix

It's added the svg namespace if it's missing, but it hasn't renamed any existing nodes has it?

Some comments.

This bug should affect all multilingual SVG that does not use English as the default.

T261192

The approach is reasonable.

T280718: Re-evaluate whether keeping around https://noc.wikimedia.org/conf/fc-list is a good practive

Many Noto fonts are in the fc-list, but NotoSansCJK is not Even "CJK" is not in the fc-list.

I do not see NotoSansCJK in the fc-list.

Duplicate en clauses had already been fixed.

There is/was an issue with duplicate en clauses.
See https://commons.wikimedia.org/wiki/File_talk:2022_Russian_invasion_of_Ukraine.svg/Archive_4#SVG_Translate_trouble

SimHei and FZYXJW--GB1-0 are not in the font list copied at T280718 or the current https://noc.wikimedia.org/conf/fc-list

The file https://commons.wikimedia.org/w/index.php?lang=qct&title=File%3AHistory_of_the_Universe_%28multilingual%29.svg uses the default font and displays the langtags qcs and qct correctly. Says the default font displays Chinese correctly.

The file https://commons.wikimedia.org/wiki/File:History_of_the_Universe-zh-hant.svg has font-family="SimHei".

Generating new requests and looking at HTTP response headers suggest Thumbor version correlation:

https://commons.wikimedia.org/wiki/File%3AAbdomal_organs_body.svg may have the same problem. It's default language is English, but not all of its translations display. The set of working translations also varies. Right now, German (de) works but Spanish (es) displays English. The corresponding image URLs are

When MW builds the page, it considers lang=en to be the default, so MW uses the src attribute

• https://upload.wikimedia.org/wikipedia/commons/thumb/d/d1/Oeffentliche_Nettostromerzeugung_Schweiz_2021_de.svg/512px-Oeffentliche_Nettostromerzeugung_Schweiz_2021_de.svg.png?20230425142331

That URL does not specify a langtag for the SVG file.

I would decline this task.

I would decline this feature request.

In T5593#8664999, @AntiCompositeNumber wrote:

In T5593#8664865, @Glrx wrote:

Translation is a small issue. Most users will not notice. If a French speaker just visits the fr.Wiki, then she will just see the French translations. It only gets weird when she visits the Japanese Wiki and starts seeing illustrations in French or English rather than Japanese. Technically, the issue can be avoided by localizing the SVG for each language wiki -- that's what is done now, but the localization is done just for the PNG and not for the SVG.

I would not call translation a small issue. Wikimedia sites have better language support than most user agents. Relying solely on browser language selection would prevent translation into all languages.

Serving SVG or PNG should be determined by the SVG file size. What is the best way to handle that choice?

I would decline this task. WMF is not in the tool business, and the tool would require enormous/impossible sophistication.

In T5593#8433694, @AntiCompositeNumber wrote:

In T5593#8433481, @Vollbracht wrote:

The only problem left seams to be the fear of security flaws that I still don't understand.

That's not entirely true. There are three main problems:

1. Security (mostly solved by using <img> instead of direct embeds)
2. Translation
3. Fonts (Webfonts are generally unsupported in <img> tags, default font support for many languages is still poor)

There are also differences between browsers on specific element support and spec compliance.

Many users want SVG served: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multimedia_and_Commons#Native_SVG_support

In T134455#8662236, @Jonathanischoice wrote:

That's all well and good, in that case, how are we to advance T5593 which has been languishing since 2005? That's nearly twenty years. I would like to see SVG Score output hopefully some time before the sun runs out of hydrogen and engulfs our planet in a fiery apocalypse.

This option is very clever. It was a way to efficiently offer both PNG and SVG.

First, @font-face with src should not be used in the vast majority of SVG files. Most SVG files need only basic fonts that can be fulfilled with the sans-serif or serif generic fonts. Even if a graphic designer has a favorite font, graphics uploaded to Commons should use fallback fonts.

In most cases, SVG should use generic fonts and be designed to work with substituted fonts.

The SVG file https://commons.wikimedia.org/wiki/File:History_of_the_Universe-zh-hant.svg has been fixed.

In T134410#8433503, @Vollbracht wrote:

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

I presume you are using --zoom

• https://gitlab.gnome.org/GNOME/librsvg/-/blob/main/rsvg-convert.rst

In T271000#8281697, @Samwilson wrote:

Testing notes

Thanks @dom_walden!

---

The first case does not have an xmlns: namespace declaration, but the second does.

The tool already adds the missing namespace if there isn't one.

I doubt that adding the namespace declaration changes the SVG file's elements. The document has already been parsed, so all the elements have had their namespace property set. SVG Translate is using a poor namespace model, so it will treat elements in the default namespace the same way as it would treat elements in the SVG namespace. SVG Translate uses getElementsByTagName() rather than getElementsByTagNameNS(). That poor model is also why the code separately checks for "svg:text". It should not be doing that. T316741: Allow svg namespace prefixes other than 'svg'

I'm looking at tests/Model/Svg/SvgFileTest.php, and I see test cases such as the two starting at line 645

'CSS too complex' => [
    'svg' => '<svg><style>#foo { stroke:1px; } .bar { color:pink; }</style><text>Foo</text></svg>',
    'message' => 'structure-error-css-too-complex',
    'params' => [0 => ''],
],
'tref' => [
    'svg' => '<svg xmlns="http://www.w3.org/2000/svg" version="1.0" xmlns:xlink="http://www.w3.org/1999/xlink">
        <defs><text id="tref-id">Lorem</text></defs>
        <text id="text"><tref xlink:href="#tref-id" /></text></svg>',
    'message' => 'structure-error-contains-tref',
    'params' => [0 => 'text'],
],

The first case does not have an xmlns: namespace declaration, but the second does.