GNOME Bugzilla – Bug 570182
pango_font_get_metrics incorrect due to pango_context_load_font choice
Last modified: 2018-05-22 12:49:20 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]);
Can you bring this up on the fontconfig list? I don't think it should be fixed in pango.
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).
(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.
> 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.
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.
> 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.
For reference, the AbiWord bug is: http://bugzilla.abisource.com/show_bug.cgi?id=11953
-- 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.