Page MenuHomePhabricator

Incorrect text positioning in SVG rasterization (scale/transform; font-size; kerning)
Closed, ResolvedPublic0 Estimated Story Points

Assigned To
Authored By
bzimport
Mar 4 2012, 10:10 AM
Referenced Files
Restricted File
May 18 2023, 2:00 AM
Restricted File
May 18 2023, 1:59 AM
F34728683: 20211103023141!Regression_lines.svg1000.png
Nov 3 2021, 10:00 PM
F34728685: 20211103023141!Regression_lines.svg500.png
Nov 3 2021, 10:00 PM
F34442058: 220px-Fonttest-Kerning.svg.png
May 5 2021, 3:48 PM
F34442061: Bildschirmfoto von 2021-05-05 17-41-19_.png
May 5 2021, 3:48 PM
Tokens
"The World Burns" token, awarded by JoKalliauer."Burninate" token, awarded by Liuxinyu970226."Meh!" token, awarded by Jc86035."Burninate" token, awarded by ToBeFree."Burninate" token, awarded by Ebe123."The World Burns" token, awarded by Perhelion.

Description

The text in these two SVGs should render identically:

However the text in the first has screwed up kerning, while the text in the second doesn't. The only difference between the two SVGs is that the first one used a small font size (3px) which is scaled up by the viewBox, while the second one uses a larger font size (24px) and is not scaled. In Firebox's native SVG renderer, they both look fine.

Screenshot of the difference (as rendered on Commons):

example-screen-shot.png (366×627 px, 28 KB)

and with render size 320px:
Rsvg_text_rendering_test_1.svg (1).png (160×264 px, 4 KB)

Ccl_climate_dividend_cycle_english.svg.png (566×800 px, 60 KB)

Details

Reference
bz34947

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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:

aaa.png (510×452 px, 59 KB)

New thumbnail:

aaa new.png (510×452 px, 58 KB)

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:

Screen Shot 2017-11-04 at 3.08.02 PM.png (278×250 px, 31 KB)

New thumbnail:

Screen Shot 2017-11-04 at 3.08.11 PM.png (278×250 px, 30 KB)

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:

O_Canada_Lilypond.svg.png (556×689 px, 42 KB)

Librsvg should be upgraded to get rid of this block.

This comment was removed by Ebe123.

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

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

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.

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)

JoKalliauer closed this task as Resolved.EditedMay 17 2023, 2:47 PM
JoKalliauer claimed this task.

There might still be kerning issues, however I consider this issue as resolved.