Ooops, you are right. The text is not stroked.

Here's another example of how our SVG text rendering has significantly degraded in the past year (please view these at full size):

Old thumbnail:

New thumbnail:

These are both thumbnails of the same SVG. Note the thinner and more pixelated text in the new thumbnail.

If you look at smaller thumbnails (the kind we typically show in articles), you start to notice significant kerning problems:

Old thumbnail:

New thumbnail:

Just spotted at https://commons.wikimedia.org/wiki/File:Mexico_1835-1846_administrative_map-en-2.svg. Uploading a transform-simplified version with SVGO to see whether it helps. (It doesn't.)

Before I saw this problem I actually enjoyed some of the spacing/hinting/gridfitting/whatever decisions at very small sizes that seems to help with legibility...

Aklapper, what svg library is your copy of imagemagick convert calling? Is it the built-in one or the rsvg one? Consider using rsvg-convert so you know you are actually using rsvg.

Supposedly this is fixed by https://gitlab.gnome.org/GNOME/librsvg/commit/c70000117fb6e7dabdb77c1c8cc1067add7da6d9, which landed in librsvg 2.40.19. See https://gitlab.gnome.org/GNOME/librsvg/issues/151 and https://bugzilla.gnome.org/show_bug.cgi?id=587721.

@MoritzMuehlenhoff: At the risk of crying wolf, any chance we could upgrade librsvg on the scaling servers from 2.40.16 to 2.40.19?

This task is blocking T49578: Score should output SVG as PNG conversion is taken up by librsvg (not ImageMagick) in the update. We get results such as:

Pinging @MoritzMuehlenhoff. Please see my most recent comment above. Thanks!

Pinging @kaldari . File:O_Canada_Lilypond.svg has a woring workaround: File:O_Canada_Lilypond_Workaround.svg

The workaround is pretty easy:
<g transform="scale(10)">
...
</g>

and ungroup everything with inkscape.

FYI, librsvg 2.40.19 (which supposedly fixes this bug) requires Pango 1.38.0 or later (released in 2015) and libxml2 2.9.0.

@MoritzMuehlenhoff: Any thoughts about the possibility of upgrading to librsvg 2.40.19 (or 2.40.20)? I know there's also a plan to migrate the image scalers to Debian stretch (T174431), which might take care of this for free, but it's not clear how soon that might actually happen.

When we migrate the image scalers to Debian stretch we'll have a refreshed graphics library stack.

@MoritzMuehlenhoff: It looks like the migration of the image scalars to Debian stretch is complete, but this bug is still present and it doesn't look like a refreshed graphics stack was included in the upgrade: https://tools.wmflabs.org/apt-browser/stretch-wikimedia/main/. Now that the migration is complete, could we manually refresh the graphics stack (or at least librsvg and its dependencies)?

The issue still exist in librsvg 2.51.1

Rendering of https://commons.wikimedia.org/wiki/File:Fonttest-Kerning.svg

Wikimedia librsvg 2.40	local 2.51.1

Comparison to other render of https://commons.wikimedia.org/wiki/File:Fonttest-Kerning_alsoCorrect.svg

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

In T36947#7076752, @Arthur2e5 wrote:

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

The lettes in indiviudal <tspan> got better (right column), but usually you use just one <tspan> for a whole word (left column), and that got worse, see T205776#7072788 and T142908#7072828 so updating librsvg to 2.50 will imho make this task even worse.

Regression reported upstream https://gitlab.gnome.org/GNOME/librsvg/-/issues/730

"Incorrect text spacing when transform is not 1:1" will be fixed in librsvg 2.51.2 (and librsvg 2.50.6, once backported) according to https://gitlab.gnome.org/GNOME/librsvg/-/issues/730 (thanks to JoKalliauer for investigation and upstreaming). It's unclear to me if this covers all the different things listed in this very ticket though.

Another issue reported downstream: https://commons.wikimedia.org/wiki/User_talk:Chen-Pan_Liao#Your_File:Regression_lines.svg

svg	PNG 1000px (abandonware: WMF-c-librsvg2.40.21)	PNG 500px (abandonware: WMF-c-librsvg2.40.21)
source-svg

Also just affected File:Systemd-on-fedora.svg. I worked around it with cairosvg, which turns all text into paths; then I copied the text elements and pasted them into the new file with fill:rgba(0,0,0,0)