Page MenuHomePhabricator

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

Assigned To
None
Authored By
bzimport
Mar 4 2012, 10:10 AM
Referenced Files
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
F34442056: 220px-Fonttest-Kerning.png
May 5 2021, 3:48 PM
F12070451: O_Canada_Lilypond.svg.png
Dec 26 2017, 7:34 PM
F10614767: Screen Shot 2017-11-04 at 3.08.11 PM.png
Nov 4 2017, 10:38 PM
F10614766: Screen Shot 2017-11-04 at 3.08.02 PM.png
Nov 4 2017, 10:38 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

StatusSubtypeAssignedTask
OpenBUG REPORTNone
OpenNone
OpenNone
OpenNone
DuplicateNone
StalledNone
StalledNone
OpenNone
StalledNone
DuplicateNone
OpenNone
DuplicateNone
StalledNone
StalledNone
DuplicateBUG REPORTNone
StalledNone
OpenBUG REPORTNone
StalledNone
OpenBUG REPORTNone
StalledNone
StalledNone
StalledNone
StalledNone
StalledNone
StalledBUG REPORTNone
InvalidNone
StalledBUG REPORTNone
StalledBUG REPORTNone
StalledNone
StalledNone
StalledNone
StalledNone
ResolvedNone
OpenNone
InvalidNone
Resolvedfgiunchedi
Resolved Gilles
Resolvedfgiunchedi
Resolvedjijiki
ResolvedNone
Resolvedjijiki
OpenNone
DuplicateNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
$:acko\> which convert
/usr/bin/convert
$:acko\> rpm -qf /usr/bin/convert 
ImageMagick-6.9.3.0-6.fc25.x86_64
$:acko\> rpm -q pango cairo harfbuzz
pango-1.40.4-1.fc25.x86_64
cairo-1.14.8-1.fc25.x86_64
harfbuzz-1.3.2-1.fc25.x86_64
$:acko\> convert -resize 320x160 Rsvg_text_rendering_test_1.svg Rsvg_text_rendering_test_1.png

creates this output which looks good to me compared to what's on the servers:

Rsvg_text_rendering_test_1.png (160×320 px, 6 KB)

Taking https://upload.wikimedia.org/wikipedia/commons/e/e1/Ccl_climate_dividend_cycle_english.svg (which also looks horrible in Firefox) and doing the same via

$:acko\> convert -resize 800x566 CO2\ fee\ and\ climate\ dividend.svg CO2\ fee\ and\ climate\ dividend.png

to compare with https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Ccl_climate_dividend_cycle_english.svg/800px-Ccl_climate_dividend_cycle_english.svg.png , it also looks fine locally:

CO2 fee and climate dividend.png (566×800 px, 126 KB)

I'll prepare a Pango build to test this on jessie

A jessie backport of Pango 1.40.4 for jessie is now available at https://people.wikimedia.org/~jmm/pango/

The update of Pango itself doesn't help on its own: I've generated a PNG with stock jessie and an updated Pango 1.40.4 here: https://people.wikimedia.org/~jmm/pango140/

It's probably a combination of other libraries which fixes that. When we migrate the image scalers to Debian stretch we'll have a refreshed graphics library stack.

I don't know if it is relevant, but the Bosch Composition.svg text was stroked. Stroked text can grow or shrink depending on the stoke width and color.

If the tspan is changing the rendered size, then that suggests that rsvg is confusing specified, calculated, and actual property values. When tspan needs a property value, it should inherit the property's calculated value from its text parent and then turn that value into an actual value that is used for rendering. Consequently, both text and tspan elements should use same calculated value and arrive at same actual value.

BTW, Bosch Composition.svg didn't have a default language for its switch translations. I set the default lang to de.

I don't know if it is relevant, but the Bosch Composition.svg text was stroked. Stroked text can grow or shrink depending on the stoke width and color.

You seem to be wrong here, there is obviously no stroke on text in the code. Your stroke="none" is unnecessary.

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)