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.

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: