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 570182 - pango_font_get_metrics incorrect due to pango_context_load_font choice
pango_font_get_metrics incorrect due to pango_context_load_font choice
Status: RESOLVED OBSOLETE
Product: pango
Classification: Platform
Component: general
1.22.x
Other All
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2009-02-02 07:58 UTC by John Wehle
Modified: 2018-05-22 12:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description John Wehle 2009-02-02 07:58:24 UTC
Please describe the problem:
The enclosed patch fixes a problem which prevents abiword-2.6.6 from
working correctly.  Tracing through the code I see:

  1) abiword GR_UnixPangoFont::reloadFont calls pango_context_load_font
     to create a 8 point Times font for a 1440 dpi device context (the
     font size in pixels is 160).

  2) pango_fc_font_map_load_font calls pango_font_map_load_fontset which
     eventually gets to pango_fc_font_map_get_patterns which calls
     pango_fc_make_pattern to make the pattern being requested.

  3) FcFontSort is called with the pattern.  It returns:

       Times 8 pixel size 34.000000
       Bitstream Vera Serif 8 pixel size 160.000000
       Luxi Serif 8 pixel size 160.000000
       ...

  4) Upon return to pango_fc_font_map_load_font it selects the first
     font in the new fontset based on the logic that FcFontSort returns
     the best fit first.  This causes the Times 8 pixel size 34.000000
     font to be used which is the exact font and point size desired
     (though the size in pixels is different).

  5) abiword GR_UnixPangoFont::reloadFont calls pango_font_get_metrics
     which calls pango_fc_font_describe_absolute who notices that the
     font has FC_PIXEL_SIZE set and calls
     pango_font_description_set_absolute_size to set the font size based
     on the font's FC_PIXEL_SIZE of 34 which then proceeds to cause the
     returned metrics to be incorrect for 8 point Times font built for
     a 1440 dpi device.

  6) As a result the document loaded (or being written) in abiword is
     displayed as a bunch of black smudges (i.e. the letters are displayed
     on top of each other).

Steps to reproduce:
1. Build abiword-2.6.6 on FreeBSD 6.4 using X11R7.3, freetype-2.3.8,
   fontconfig-2.6.0, glib-2.18.4, and pango-1.22.4.  This is without
   gnome and with printing disabled.  You'll need the patch in abiword's
   bug database which fixes the startup crash on FreeBSD due to UCS-2 / USC-4
   mapping.

2. Run abiword.

3. Try entering Hello World.


Actual results:
Hello World displays as a black smudge.

Expected results:
Hello World to display in a readable fashion.

Does this happen every time?
Yes.

Other information:
This patch appears to fix the problem.
--- pango/pangofc-fontmap.c.ORIGINAL    2008-12-16 01:14:00.000000000 -0500
+++ pango/pangofc-fontmap.c     2009-02-02 02:21:35.000000000 -0500
@@ -1100,6 +1100,13 @@ pango_fc_font_map_get_patterns (PangoFon

       for (f = 0; f < font_patterns->nfont; f++)
        {
+         double size;
+
+         if (FcPatternGetDouble (font_patterns->fonts[f], FC_PIXEL_SIZE,
+                                 0, &size) == FcResultMatch
+             && fabs (size - (double)key.scaled_size / 1024) >= .5)
+           continue;
+
          font_pattern = FcFontRenderPrepare (NULL, pattern,
                                              font_patterns->fonts[f]);
Comment 1 Behdad Esfahbod 2009-02-02 15:29:38 UTC
Can you bring this up on the fontconfig list?  I don't think it should be fixed in pango.
Comment 2 John Wehle 2009-02-02 18:16:01 UTC
FcFontSort is documented as returning a set of fonts
sorted by closeness to the request.  From a certain
point of view a font matching the requested name is
a closer fit than a different font which matches the
requested pixel size.

It's not clear to me that the problem is with FcFontSort
... it is after all working as described (i.e. returning
a selection of fonts for your consideration based on
the requested pattern).
Comment 3 Behdad Esfahbod 2009-02-03 03:36:59 UTC
(In reply to comment #2)
> FcFontSort is documented as returning a set of fonts
> sorted by closeness to the request.  From a certain
> point of view a font matching the requested name is
> a closer fit than a different font which matches the
> requested pixel size.
> 
> It's not clear to me that the problem is with FcFontSort
> ... it is after all working as described (i.e. returning
> a selection of fonts for your consideration based on
> the requested pattern).

That's why I suggested writing to the fontconfig list, not filing a bug against fontconfig.  If your argument was to be followed, pango is choosing the right font in the same sense and hence there is no bug.
Comment 4 John Wehle 2009-02-03 05:59:24 UTC
> if your argument was to be followed, pango is choosing the right
> font in the same sense

Perhaps there's similarities, though it's not exactly the same.  It
seems to me that it's fairly clear that FcFontSort returns possibilities
... a further decision is required on the part of the application.
pango_context_load_font is expected to make the decision so as a
result it has a larger responsibiliy to ensure that the chosen font 
is appropriate for the context (which after all is part of the function
name).  

> and hence there is no bug

Not exactly ... pango_context_load_font was requested to produce a 8 pt 
font for a 1440 dpi device.  The problem is that pango_font_get_metrics
is returning information which doesn't reflect that choice.  If we go 
with the notion that the choice of Times 8 pt pixel size 34.000000 is
okay, then the bug is with pango_font_get_metrics, otherwise the bug
is with pango_context_load_font.
 
This is something that hopefully someone who knows the internals of
pango can hopefully help with.  For example should pango_font_get_metrics
be calling pango_fc_font_describe_absolute?  

Should pango_fc_font_describe_absolute be looking at FC_PIXEL_SIZE?  For
that matter ... what does FC_PIXEL_SIZE mean anyway?

How should pango generate the information which is returned by
pango_font_get_metrics?  Perhaps this is a pango bug, perhaps it's
a fontconfig bug ... I'd hope that the issue could be sorted out
between the pango developers and the fontconfig developers.
Comment 5 Behdad Esfahbod 2009-02-03 18:08:47 UTC
I don't want to be rude, but all I asked you was a simple question: "Can you bring this up on the fontconfig list?"  Now I understand that you won't, so I'll do it myself.

In another note, I think you are using pango wrongly.  You shouldn't set a the physical device DPI as pangocairo context resolution.  For PS/PDF/..., the resolution should be set to 72.
Comment 6 John Wehle 2009-02-04 08:08:23 UTC
> I don't want to be rude, but all I asked you was a simple question

Sorry .. perhaps I should have answered the question by directly
saying from what I could see this seemed like a pango issue and I
was unclear on what the fontconfig question was that I should bring
up on the fontconfig list which I know nothing about.

> Now I understand that you won't, so I'll do it myself.

Okay ... you probably have a better understanding on what to ask
so thanks for pursuing this in what you feel is a more appropriate
setting.  Seriously ... I appreciate you taking the time.

> In another note, I think you are using pango wrongly

For what it's worth ... abiword is using the DPI of it's internal
layout device which is defined as 1440 DPI.  It is not using
a physical device DPI (at least with regards to this issue).

> pangocairo context resolution. For PS/PDF/

I'm not sure how pangocairo, PS, or PDF enter into the picture.

Note: I'm not an abiword, pango, or fontconfig developer.  I have
no stake in this other than wanting to be able to use abiword and
I am an experienced developer willing to track down the problem I
was having.  I.e. I'm not in a position to explain or justify how
abiword functions.

Looking further at the problem leads me to believe that
pango_font_get_metrics is working correctly in the sense that I
believe that metrics which are being returned are correct for the
chosen font.

The issue seems to be what can an application expect from
pango_context_load_font.  All the documentation says is it loads
the closest match.  However, it doesn't define what that means.
So the question becomes when asked for Times 8 pt 160 pixel is it
better for pango to return Times 8 pt 34 pixel which might not be
readable, or to return Vera 8 pt 160 pixel which is a different font?

In any event I've logged bug id 11953 in bugzilla.abiword.com along
with a patch for abiword which makes defining the exact behavior of
pango_context_load_font somewhat less pressing.
Comment 7 Hubert Figuiere (:hub) 2009-07-21 17:35:53 UTC
For reference, the AbiWord bug is:

http://bugzilla.abisource.com/show_bug.cgi?id=11953
Comment 8 GNOME Infrastructure Team 2018-05-22 12:49:20 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/149.