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 566488 - When attempting to linearly scale a PangoLayout, some font backends do not report correct logical extents
When attempting to linearly scale a PangoLayout, some font backends do not re...
Status: RESOLVED OBSOLETE
Product: pango
Classification: Platform
Component: cairo
1.22.x
Other Linux
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2009-01-04 09:59 UTC by Andrew Cowie
Modified: 2018-05-22 12:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Demonstrate extents problem (4.66 KB, text/plain)
2009-01-04 10:08 UTC, Andrew Cowie
Details

Description Andrew Cowie 2009-01-04 09:59:51 UTC
A problem that occurs when you use Cairo to linearly scale a Context that you are drawing to with pango_cairo_show_layout(): the height reported in the logical PangoRectangle from pango_layout_line_get_extents() are wrong, as is the word wrapping done in the PangoLayout.

I've prepared a C program that hopefully demonstrates the issue.

I finally tracked it down to calling pango_layout_get_baseline(). I had been calling it before I set any text into the PangoLayout (which is hopefully no shock; you need that for an initial depth before looping over a series of paragraphs).

So it would seem that one bug is that an entire PangoLayout gets screwed if pango_layout_get_baseline() is called on an empty PangoLayout; the workaround in both this test program and in the java-gnome code where this was first noticed was:

   pango_layout_set_text(layout, "Hello");
   b = pango_layout_get_baseline();

But there's more, and worse:

Serkan Kaba duplicated this bug for me. However, getting it to appear for him was difficult, because...

He didn't have the Liberation font family installed. So whatever his system was falling back to *did* work. We installed Liberation on his system, and then the bug appeared. Which makes me think that the real problem is in one or more of the Font rendering backends, but that's just speculation on my part.

I tried changing the font description string on the program on my system, and:

   "Liberation Serif, 12" - extents borked
   "Bitstream Vera Sans, 12" - extents borked
   "Serif, 12" - extents CORRECT!

So what the hell? But if this program works for you, trying playing with the specified font.

AfC
Comment 1 Andrew Cowie 2009-01-04 10:08:21 UTC
Created attachment 125730 [details]
Demonstrate extents problem

Small GTK program illustrating the problem. The usual instructions for building a one-off like this are included in file comments anyway. If you don't see the bug when running this, try with a different font.

AfC
Comment 2 GNOME Infrastructure Team 2018-05-22 12:45:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/147.