I'm not sure about to handle this bug, because librsvg is used for speed. This seems more a bad and rare code from ChemDraw (anyway there could be more). As we can see LibRsvg pass all the W3C text-anchor test (with except of text on path and vertical, more than Chrome 42 which don't pass one test):

• http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/text-align-01-b.html
• http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/text-align-03-b.html
• http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/text-align-04-b.html

ChemDraw workaround (posted by Leyo): "I get the best results, if I first save the structure as .eps. I then convert the .eps to .svg using Scribus."

That's still an issue with librsvg 2.40.16, it renders the attached SVG like this: https://people.wikimedia.org/~jmm/svg/alanin.png

I mean now this is a bug of ChemDraw, because the text-tag needs x/y values (after W3C specifikation). (As this issue was newly reported on the German SVG-Projekt. https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_SVG#Chemdraw_Dateien) The browser and editor interpretation seems only fallback fault tolerance calculating.
@MartinK has created an JS-tool to fix such files: http://tools.martinkraft.com/fixChemdrawSvg.html.

This issue still occurs in librsvg 2.44.10:

I could not find an upstream bug report for this

I upstreamed as https://gitlab.gnome.org/GNOME/librsvg/-/issues/651

Fixed in librsvg 2.50.2 via https://gitlab.gnome.org/GNOME/librsvg/-/commit/327088cbc22018bfa479b3a0282eb244e7804da4

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.)

Another test file:

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

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

The recent upgrade of Debian introduced the 2.44.10 Rust librsvg that still had this issue.

Consequently, many files that previously worked now show this bug.

See

• T336894
• https://commons.wikimedia.org/w/index.php?title=Talk:Librsvg_bugs&diff=prev&oldid=791631775#SVG_text_rendering:_probable_bug

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

Another file is displayed incorrectly.

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

T344564 shows another librsvg 2.40 to librsvg 2.44 regression issue.

Another victim:

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

Also https://commons.wikimedia.org/w/index.php?title=User_talk:Cmglee&diff=prev&oldid=809256563

@Glrx: I don't think this task has high priority as it entirely depends on upgrading librsvg to version >=2.50.2, which means upgrading machines to Debian Bullseye, which makes this task depend on T265549?

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.

Even if WMF uses Bullseye, WMF should be using more recent versions of librsvg.

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.

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.

In late May 2022, @WDoranWMF sent emails that stated

Currently, we're working on migrating Thumbor to the latest versions of Python, Thumbor and Debian. Alexandros Kosiaris(akosiaris) pointed me toward you. I wanted to ask for help in validating the new version of Thumbor.

We're ~60% of the way through the migration of the code base, though it is not necessarily a linear path and we may yet encounter blockers. Our current target is to have the new version of Thumbor running on our production kubernetes cluster toward the start of July. The service would not be receiving traffic yet but it would capable of doing so.

Right now we're starting to build our rollout plan that we will undertake from July to September. That will involve testing and validation of the new service to ensure that it performs at the expected level and that there are no regressions.

Another user has complained about this 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

Thumbor is busted. This bug is not stalled on librsvg; versions from a year ago do not have this bug.

Another user bitten by the bug:

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

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

I've described some workarounds on

http://en.wikipedia.org/wiki/Wikipedia:SVG_help#Misaligned_text

Feel free to add or amend any. Cheers, ~~~~

Another report:
http://en.wikipedia.org/w/index.php?title=Wikipedia:SVG_help&diff=prev&oldid=1188309574

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

Same issue here: https://commons.wikimedia.org/wiki/File:SporadicGroups.svg

This file seems to show the problem: SVG text positioning.svg

Same issue: https://upload.wikimedia.org/wikipedia/commons/thumb/a/a1/QM_AM_GM_HM_inequality_visual_proof.svg/360px-QM_AM_GM_HM_inequality_visual_proof.svg.png

We don't need to list every file with this issue in the ticket. It's known that this is broken for a considerable subset of files.

Yet another file hit by this bug: https://commons.wikimedia.org/wiki/File:Quadratic_function_graph_key_values.svg

Everybody knows that it's pointless to list more files here. Spamming this task is an expression of our frustration.

In T97233#9656083, @Tercer wrote:

Yet another file hit by this bug: https://commons.wikimedia.org/wiki/File:Quadratic_function_graph_key_values.svg

Everybody knows that it's pointless to list more files here. Spamming this task is an expression of our frustration.

In that case, your time will be better spend learning how to make Debian packages and writing Gerrit patches, or running for the Wikimedia board.

I think my time is better spent doing what I know, which is editing articles about quantum mechanics on Wikipedia. And if you point out an issue there, I'm not going to suggest that you have to learn quantum mechanics yourself or otherwise pound sand.

I see that you're a volunteer, so I can't really ask you to do such boring maintenance work as installing a bugfix that was released four years ago. I can, however, ask you to refrain from insulting contributors.

Look. The people on this task are the people who are annoyed by it already. Complaining more here won't get you anywhere. Complain to WMF management, who are the people who can allocate resources to this.

I have: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)#Proposal:_WMF_should_hire_a_full-time_developer_to_do_basic_maintenance_on_MediaWiki