After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694918 - Pango layout is rendered in wrong size if we have non-identity cairo transformation matrix
Pango layout is rendered in wrong size if we have non-identity cairo transfor...
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: cairo
1.33.x
Other Windows
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2013-03-01 07:57 UTC by Alexey Kosilin
Modified: 2013-05-02 17:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alexey Kosilin 2013-03-01 07:57:00 UTC
pango-1.33.7 + cairo-1.12.14 + librsvg-2.37 renders attached svg incorrectly in case of scaled cairo context. Both of render results (wrong and right) is also placed in archive attached.

As I have investigated the problem is in lines 255-256 of pangocairo-win32font.c (pango-1.33.7). These lines was added in folowing commit: http://git.gnome.org/browse/pango/commit/?id=b359bb484bc7d27a835cfd6d9ffcaed582ebf2ae not so long ago.

The commit's comment notes us that these lines is neccessary "to take cairo CTM into account", but in fact the CTM is taken into account something else - commenting out these lines gives right render result. It's quite obvious for me because the CTM in my case (rendering the svg attached using librsvg in my context) shows approximately 0.13 scale factor.

Second, the discussed code is unclear completely: why we should increase font size in case CTM directs us to reduce it (line 256: size /= ...)? What is more it gives to incorrect result in case presence of CTM.
Comment 1 Behdad Esfahbod 2013-03-04 22:43:28 UTC
Thanks.  I'll take a look.
Comment 2 Behdad Esfahbod 2013-03-04 22:44:00 UTC
Thinking about it, I believe you are right.  I remember now why we need this in the fontconfig-based backends, but not win32 or quartz.  Fixing.
Comment 3 Behdad Esfahbod 2013-03-04 22:47:51 UTC
commit 25ad29b488d3e2ae10e4fee25602409fa39207f1
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Mon Mar 4 17:45:03 2013 -0500

    Revert "Fix Win32 and CoreText cairo backends to take cairo CTM into
    
    This reverts commit b359bb484bc7d27a835cfd6d9ffcaed582ebf2ae.
    
    Bug 694918 - Pango layout is rendered in wrong size if we have
    non-identity cairo transformation matrix
    
    I was wrong blindly copying this logic from pangocairo-fc into
    pangocairo-win32 and pangocairo-quartz.
    
    The reason we need the it in pangofc is because the fontsize we
    get back from fontconfig is multiplied by the ctm scale factor,
    so we undo it when loading the font.  The same is NOT true about
    the non-fc backends, so the copying was totally wrong.
Comment 4 Behdad Esfahbod 2013-05-01 18:38:40 UTC
Report on mailing list:

Today I upgraded pango to the latest version (1.34.0), and found that the fix

https://git.gnome.org/browse/pango/commit/?id=b359bb484bc7d27a835cfd6d9ffcaed582ebf2ae

has been reverted:

Bug 694918 https://bugzilla.gnome.org/show_bug.cgi?id=694918

Then my original problem reappears, at least on Mac (I can't test on Windows).
If I set CTM to (1/2)*unit_matrix, then an extra factor of 1/2 is mysteriously
applied "somewhere" in the library and the fontsize is scaled not by 1/2
but by 1/4=(1/2)*(1/2).

Jun
________
Comment 5 Behdad Esfahbod 2013-05-01 18:39:20 UTC
Quite possibly we need the scale in the Mac backend but not Windows.
Comment 6 Behdad Esfahbod 2013-05-02 17:42:34 UTC
Ok, fixed it I believe.