Gnome says issue fixed in librsvg 2.59.2.

I copied the Green_check.svg thumbnail to my clipboard and then pasted it into https://onlinepngtools.com/analyze-png (a random tool on the internet)

IIRC. SVG files are sRGB. PNG files do not have a default color space, but one can be declared. The PNG output by librsvg does not set the color space.

It has been a long time since I have looked at MIDI files, but I do not believe there is a field that states the duration. The file must be interpreted to determine the duration.

My vague, ancient, memory is SVG files without an XML processing instruction used to be tagged as text/plain.

WMF serves the problem SVG files as CONTENT-TYPE text/plain. I do not know where WMF makes that decision.

In T65236#10409337, @Aklapper wrote:

Was this fixed by T265549 or should that subtask be removed and it's only fixed after librsvg 2.50.3?

In T40010#10252569, @Bawolff wrote:

Re glrx:

I'm not an expert, but I think that change would be localized to Thumbor. If Thumbor is asked to rasterize an SVG file, it can notice the file is small and then serve it directly. If Thumbor sets the MIME type, then I think the img element will display it properly. But it also butchers the current semantics. A URL that formerly always gave a PNG file now might give an SVG file. Some OCR code I use will not take SVG but will take PNG; I use something like {{filepath:foo.svg|800}} to get a PNG. Maybe add something to the URL that requires a PNG or obey HTTP requests that ask only for a PNG MIME type.

While this is an option, i actually think its better to not have thumbor involved at all. I think it would be better to just make files with systemLanguage attributes always be rasterized (at least in the beginning). For other files i think we should treat it similar to jpgs, where sometimes we thumbnail and sometimes we send the original asset.

There are many issues with WMF's support of SVG.

In T271663#10238807, @Pppery wrote:

In T271663#9952626, @Arthur2e5 wrote:

If we're talking about File:SVG_Test_TextAlign.svg: I believe the RTL issue as shown by the KV 15 arabic text is being shown correctly on Commons now. As a result, *if* we get SVG Translate Tool to flip start/end, it will work as expected.

Several other rsvg bugs shown have not yet been fixed, but I do not believe they affect this request.

Assuming that means this task can be closed as resolved.

Dupe of T20463?

I'm located on the US west coast.

https://gitlab.gnome.org/GNOME/librsvg/-/issues/967
[regression] scale with text-anchor="end" leads to offset

I think this is the text-chunk bug T200443.

Could someone please check if this problem persists in more recent librsvg versions? Thanks.

This problem is showing up in several places.

I would decline this request.

Close a duplicate failed. trying again.

This looks like the text-chunk regression bug.

In T337139#9911986, @Quiddity wrote:

Hi @Snaevar (or anyone), given that the proposed parser function hasn't been merged yet, I'm wondering if you have any suggestions on how to most clearly help the editors who might need some guidance?

Ideally, I think we could write something like this, but I'm not sure if it's accurate enough, or detailed enough:

Editors who work with multilingual SVG files can add language tags to the SVG's labels. If the SVG contains labels that use a hyphenated Wikimedia specific language code that doesn't match the BCP47 standard, such as zh-classical, then those labels need to be changed to use the BCP47 code instead, such as lzh.

IETF langtags can be longer than 8 characters: e.g., zh-Hans-CN and sr-Latn-RU. The pieces between the hyphens are limited to 8 alphanum characters.

• https://www.rfc-editor.org/rfc/rfc4646.txt

In T97233#9458153, @Colinstu wrote:

Running into this rendering issue here: https://en.wikipedia.org/wiki/File:Reciprocal_altruism_summary.svg

I would decline this task. Keep the task simple. I do not see a compelling need for this feature.

The problem is with the SVG and not with MW or the render. The text is long enough that it overruns the margin. The SVG should defend against this problem by making sure the text has enough room. Although SVG is scalable, fonts do not scale linearly.

Some time ago, I learned that the langtags were stored in the MW database (they are a bit buried in the API). I'm not a MW expert.

MediaWiki uses librsvg to paint SVG files.

I just fixed a text positioning issue in a file and triggered this bug:

• https://commons.wikimedia.org/wiki/File:Basis_of_Membrane_Potential2-en.svg

Another user bitten by the bug:

• https://commons.wikimedia.org/w/index.php?title=Commons:Graphics_village_pump&diff=prev&oldid=821494579

Why is this task stalled? Rust is available on the Debian upgrade.

Yet another victim of the T97233 tspan regression:

• https://commons.wikimedia.org/w/index.php?title=Commons:Graphic_Lab/Illustration_workshop&diff=prev&oldid=814291771#File:Sum_and_difference_of_2_cubes.svg

In T97233#9249205, @hnowlan wrote:

In T97233#9248038, @Glrx wrote:

I see fixing this issue as a high priority. It is confusing many users and probably affects thousands of files. Librsvg does not follow the fundamental rules about painting text.

I raised the priority of T265549 to high (it was low). Librsvg should be upgraded to fix SVG issues independently of upgrading to Bullseye.

When will WMF use Bullseye? IIRC, Buster was promised for July 2022 but was not released until April 2023.

Work on migrating to buster didn't even start until July 2022 so wherever stated that was very incorrect.

Support for Thumbor is in the process of being moved between teams, upgrading librsvg versions will be addressed as soon as we can.

Some rank speculation.

In T337199#9256106, @TheDJ wrote:

Clicking like that takes you to the raw original SVG, which means the browser renders them instead of Mediawiki, and browsers don’t support SVG translations. So yes, this is expected. Translations only work in the thumbnails, and naturally if people make very large drawings, those won’t be very readable, unless you have a desktop screen and use the media viewer. This is documented on the SVG help page and has always been like that.

I see fixing this issue as a high priority. It is confusing many users and probably affects thousands of files. Librsvg does not follow the fundamental rules about painting text.

Following remark of Aklapper in T97233, raising priority to high. Many users are stumbling across that regression bug.

Another victim:

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

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.