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

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


and with render size 320px:

Details

Reference
bz34947
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz34947.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Mar 4 2012, 10:10 AM
brion added a comment.Mar 8 2012, 12:41 AM

I can confirm this is rendering incorrectly; not obvious why. Text looks like it's done straightforwardly, doesn't have any manual positioning or other odd things.

Could be a bug in rsvg or with the font...

Should check this once bug 31122 is fixed.

TheDJ added a comment.Oct 26 2012, 9:54 AM

This problem still exists.

I've analyzed the file. It is an extremely high ratio of scaling and font size. ~900:1. The affected file has an scale of ~900. The other unaffected SVGs are nearly equal with the difference that the font-size is ~900.

So you can simple fix this test:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="2000 -20000 30000 20000" width="750" height="600">
<text transform="translate(12296,-3469) scale(1,1)" font-size="900" style="font-family:Nimbus Roman No9 L">Prelude in B major</text>
<text transform="translate(12296,-6000) scale(910,910)" font-size="1" style="font-family:Nimbus Roman No9 L">Prelude in B major</text
</svg>

scaled & not scaled font

Attached:

[[:File:Fonttest-Kerning.svg]]

Old example of font-kerning from German SVG-help page. It shows the dependency between font transformation/scaling and size.

Attached:

Menner updated the task description. (Show Details)Apr 25 2015, 8:01 AM
Menner set Security to None.

Interesting report and examples on https://commons.wikimedia.org/wiki/Commons:Village_pump#SVG-to-PNG_convertor_text

I'm wondering he (User:Delphi234) report this as new. He used a font-size of lower than 1px, which made the effect of this bug to showing extreme.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 21 2015, 2:39 PM
kaldari renamed this task from Incorrect text positioning in SVG rasterization (scale/transform : font-size; kerning) to Incorrect text positioning in SVG rasterization (scale/transform; font-size; kerning).Aug 10 2016, 8:03 PM
kaldari updated the task description. (Show Details)

@brion: Can you confirm whether this is a local issue or an upstream issue? See the new test cases in the description.

kaldari updated the task description. (Show Details)Aug 10 2016, 9:29 PM

@MoritzMuehlenhoff, @Menner: Could one of you test and see whether this is a local issue or an upstream issue? I don't have the stack set up on my local machine. See description for test case.

@kaldari: We're using the most recent recent librsvg release and don't apply WMF-specific patches. This should be reported upstream, it's most certainly a librsvg build.

@MoritzMuehlenhoff: Sure, just let me know which version we are using.

@kaldari : We're using 2.40.16 on the image scalers, which is the latest upstream release (https://download.gnome.org/sources/librsvg/2.40/), there's also no significant changes in git after that release.

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

Perhelion added a comment.EditedApr 6 2017, 1:52 PM

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 Normal 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


Perhelion updated the task description. (Show Details)Apr 6 2017, 3:04 PM

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

Glrx added a subscriber: Glrx.Apr 6 2017, 5:41 PM

@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:

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

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:

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.

Glrx added a comment.May 5 2017, 10:09 PM

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.

Perhelion added a comment.EditedMay 6 2017, 12:29 PM

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.

Glrx added a comment.May 6 2017, 2:27 PM

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

kaldari added a comment.EditedNov 4 2017, 10:17 PM

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?

Ebe123 added a subscriber: Ebe123.Dec 26 2017, 7:34 PM

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:


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>

dann alle Gruppen mit inkscape auflösen.

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.

ToBeFree added a subscriber: ToBeFree.