Page MenuHomePhabricator

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

Assigned To
None
Authored By
bzimport
Mar 4 2012, 10:10 AM
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

@MoritzMuehlenhoff: Looks like this was already reported upstream. They suggest updating Pango to 1.40.1 or later. Can you give me the version numbers for all of the following: Pango, Cairo, and Harfbuzz? Thanks!

We're using the following versions:

Pango 1.36.8
Cairo 1.14.0
Harfbuzz 0.9.35

BTW, there's been a new release yesterday: https://mail.gnome.org/archives/desktop-devel-list/2017-January/msg00001.html

Getting that to our current servers will prove quite challenging, though: Rust is not available in Debian jessie and non-trivial to backport; it requires more recent versions of LLVM and binutils that what we have in jessie. Also, Rust needs a Rust compiler for bootstrapping...

@MoritzMuehlenhoff: According to the upstream discussion: "The bug is present with Pango 1.36.8 (openSUSE 13.2), but does not happen with Pango 1.40.1 (openSUSE Tumbleweed)." Would it be possible for us to only upgrade Pango?

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

I mean this is the absolutely major SVG and text bug. Even very experienced users produce crap (reported): https://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#Inkscape_fonts_not_recognized
I also mean the appearance of this bug get much more worse as in the past. As upstream mentioned "This is an *extremely* serious bug!". Wikimedia: who cares?

Perhelion raised the priority of this task from Medium to High.Apr 6 2017, 2:32 PM
Perhelion updated the task description. (Show Details)
Perhelion set the point value for this task to 0.

@kaldari : It's not entirely trivial since Pango has reverse deps, but we can investigate the finer details as needed. But before we invest all that effort, we should have some confirmation that this is actually an effective fix, e.g. by reproducing this in a jessie labs instance and then upgrading to 1.40 after that.

I made a test on old text image with purge, the result is horrible: (unfortunately I saved the previous 350px image to late, with best compare size) https://commons.wikimedia.org/wiki/File:Meta_SVG_fonts.svg

Meta_SVG_fonts.svg (3).png (200×320 px, 17 KB)

Meta_SVG_fonts.svg (3) after.png (200×320 px, 16 KB)

As the author of the green circular diagram, I appreciate the efforts being made to fix this bug. Robbie.

@kaldari : It's not entirely trivial since Pango has reverse deps, but we can investigate the finer details as needed. But before we invest all that effort, we should have some confirmation that this is actually an effective fix, e.g. by reproducing this in a jessie labs instance and then upgrading to 1.40 after that.

@MoritzMuehlenhoff: That's not something I would have the knowledge or ability to do. Any suggestions who might be able to accomplish that?

In Firebox's native SVG renderer, they both look fine.

For the records, not here anymore (but you may use a different backend). The SVG image looks like this in firefox-52.0.2-2.fc25.x86_64:

tx.png (205×854 px, 38 KB)

$: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.