GNOME Bugzilla – Bug 307196
Unhinted fonts are measured incorrectly and drawing problems occur as a result
Last modified: 2006-04-29 05:54:09 UTC
Please describe the problem: Please see enclosed screenshots for evidence. I think the height of unhinted fonts is being miscalculated. None of the problems described occur with hinted fonts. Steps to reproduce: 1. Disable hinting either from fontconfig or through gnome-font-properties. Actual results: Strangeness is observed Expected results: No strangeness to be observed Does this happen every time? Yes Other information: See attached screenshots. There is also problems with many programs with status bars. When there is no status message, the status bar will be x pixels high. When there is a status message, it grows to x+1 and causes a jerk in the window which is very distracting. For an example, see gnome-volume-control and hover over each control slider with your pointer. Then move away, and back on, and off, it's very apparent on all of my GNOME systems across Fedora, Gentoo and Ubuntu.
Created attachment 47570 [details] Metacity window title bars You can see that the window menu bar is being drawn too tall. This is undoubtedly because the window title bar is estimated to be x pixels tall, and the window is drawn inside to compensate that height. However when the text is drawn, it stretches the title bar an extra pixel tall and creates the problem at the edges.
Created attachment 47572 [details] gedit line heights When you add an empty line in gedit, and add more content underneath, typing anything into the empty line causes the entire rest of the document beneath to shift down one pixel. Deleting it causes it to shift up one pixel. Again, this is evidence of font height miscalculation. For proof, either try it yourself, or compare the line height of the empty and non-empty lines in the screenshot.
Created attachment 47574 [details] evolution underline mess Observe the lack of underline half way through the link bugzilla sent me. Selecting the text here causes all sorts of redrawing confusion and bits of line get left over all over the place. There are a few other bugs in Evolution's message display that are obviously caused by the same problem, but I won't go into them.
What Pango version? See bug 167801 fixed in pango-1.8.1.
Using 1.8.1.
It would seem that pango bug was to do with letter width as opposed to letter-height, too.
Can someone confirm this please?
When I get a chance to study the bug in detail, I'll comment on it. In any case, I don't pay attention to UNCONFIRMED vs. NEW.
2005-07-21 Owen Taylor <otaylor@redhat.com> * pango/pangoxft-font.c (_pango_xft_font_new): Force on metrics hinting for all Xft fonts (this fixes font metrics - glyph metrics were fixed earlier). (#307196, Alex Jones)
*** Bug 170194 has been marked as a duplicate of this bug. ***
Iiiit's baaaack. :( Tested with GNOME 2.12 live CD and Ubuntu Breezy.
Also tested with GNOME 2.12. This is definitely back. Exactly the same problems as before. :(
Bollocks, I meant to say "GNOME 2.12 in Gentoo". Sorry for the spam guys.
I can also confirm this. Marking NEW.
Any word on what went wrong? Having a perfect-looking desktop was nice for a few weeks till I upgraded to 2.12. :(
Created attachment 54800 [details] [review] experimental patch I cannot reproduce the problem. Can you try the attached patch? Apparently what happening is that with GNOME 2.12, Pango is used using cairo backend, not Xft. So the old hack is not hit anymore. The patch applies a similar hack to the cairo backend, but I'm not sure whether it works.
*** Bug 319027 has been marked as a duplicate of this bug. ***
Another example of that bug is given in bug #163016 - ellipsis is wrong in some places such as the epiphany bookmark bar.
I cannot reproduce it using Pango+Cairo. Someone who can should test the patch I attached.
From Owen: The patch isn't really right. I designed the pango-cairo stuff to avoid needing any hacks like that. That's why there are separate: cairo_font_options_set_hint_metrics() cairo_font_options_set_hint_style() So, what needs to be checked is: - Is hint_metrics always being set to TRUE by the GTK+ code to set font options? hint_metrics = FALSE should never be set for user interface code. - Is it being honored properly by the combination of Pango and Cairo?
Created attachment 55070 [details] [review] Gtk+ patch to set metrics hinting on Ok, thanks to Owen's comments, I think this patch to Gtk+ solves the problem. Metrics hinting was not being set at all in Gtk+. The patch turns it on. Someone who can reproduce the problem should confirm that the patch does solve their problem before I go on and commit.
After applying the patch I'm still seeing the issue with hinting set to None...
I'd like to test this, but it's very difficult with Gentoo ebuilds. If I can sort it out I will report back. Why was it fixed before but not now?
I explained the reason in comment 16.
Oh yeah sorry, missed that. Anyway, applied the patch but still not fixed. Exactly the same visuals as before. D'oh!
I'm now using Gtk+ 2.8.9, and though the changelog would suggest otherwise, all issues are still exhibited.
The Gtk+ patch is needed for a fix, but apparently not enough, as reported in comment #22 and yours. I have no idea what's not working as I still cannot reproduce the problem )-:.
I am astonished that you can't reproduce this, as it is apparent on five completely separate installations, including the Ubuntu Live CD. Can you turn off font hinting, take a screenshot of a window with window borders intact, and then attach it here, please?
This message looks related: http://mail.gnome.org/archives/gtk-i18n-list/2006-January/msg00005.html
Created attachment 56822 [details] screenshot Screenshot of gedit, with hinting off. Glib+Pango+Gtk+ from HEAD, on an updated FC4.
Hi Behdad 12pt fonts work fine for me, too. Try lowering it to 10pt like mine, or play with another font size. Then try copying this screenshot. http://bugzilla.gnome.org/attachment.cgi?id=47572&action=view If you add a blank line in the middle, then type a single character and press delete, type it again and press delete, you'll see that the lines underneath jump down one or two pixels. This is similar behaviour to when you insert a character with more height than the main font height, e.g. U+789 "މ".
Sorry for the spam, but a question... How does pango "guess" the font height for a specific size?
Cannot reproduce using Breezy Badger.
Using the "experimental patch" that was marked obsolete actually fixes the problem for me. Looking at the source code, it seems to me that the is_hinted flag in the patch only does a few things: 1. It makes underlines and strikethroughs strokes integer-wide if this is set. 2. It causes pango to use precalculated (cairo's?) metrics for ascender/descender when calculating the height. If not enabled, pango seems to use a freetype fixed multiply functions to calculate the height. I can understand that the first behavior might not be desired, but I don't believe the second is correct. Pango shouldn't be overriding cairo's calculations.
It really is worse than ever now, guys, hinted or otherwise. Gedit highlights the issue terribly. :( It seems the OTT font kerning causes hell to break loose between differently formatted spans of text. See "opposing bracket highlighting" image attached, and notice the difference between the top "<?php" and the bottom "<?php".
Created attachment 63184 [details] messed up widths now
Did you try Pango from CVS HEAD now?
Hi Behdad If you have any idea how I can install it into my Gentoo system into /usr/local and then uninstall it cleanly later, I will gladly try it out. As it happens with these things, I can never get them cleaned out when I no longer want them. :embarrassed:
I can reproduce this. I'll test the patch to gtksettings and see what happens.
IIRC, HINT_METRICS_ON is the default, so I really don't think the GtkSettings patch is relevant. Certainly there is not to be any funky dependency between the different font options... changing the outline hinting won't change the metrics hinting or vice versa. It's more likely to be a typo in one of the intermediate layers, or incorrect implementation in Cairo.
Ok, thanks to Fed, I can reprod this now. setting to 111dpi and Bitstream Vera Sans 12 made it hit. Turns out the issue is exactly what Brandon mentions in comment #34. pangocario-fcfont is using pangofc for font metrics, not cairo. The reason is that pangofc computes all those strikethrough and underline positions that cairo doesn't. So here is the calling code in pangocairo-fcfont.c: pango_cairo_context_set_font_options (context, cffont->options); info->metrics = pango_fc_font_create_metrics_for_context (fcfont, context); and the relevant bits is in pangofc-font.c:get_face_metrics(), which as was noted in comment #34, depends on fcfont->is_hinted: if (have_transform) { FT_Vector vector; vector.x = 0; vector.y = face->size->metrics.descender; FT_Vector_Transform (&vector, &ft_matrix); metrics->descent = - PANGO_UNITS_26_6 (vector.y); vector.x = 0; vector.y = face->size->metrics.ascender; FT_Vector_Transform (&vector, &ft_matrix); metrics->ascent = PANGO_UNITS_26_6 (vector.y); } else if (fcfont->is_hinted || (face->face_flags & FT_FACE_FLAG_SCALABLE) == 0) { metrics->descent = - PANGO_UNITS_26_6 (face->size->metrics.descender); metrics->ascent = PANGO_UNITS_26_6 (face->size->metrics.ascender); } else { FT_Fixed ascender, descender; descender = FT_MulFix (face->descender, face->size->metrics.y_scale); metrics->descent = - PANGO_UNITS_26_6 (descender); ascender = FT_MulFix (face->ascender, face->size->metrics.y_scale); metrics->ascent = PANGO_UNITS_26_6 (ascender); } So, like Brandon, the seemingly useless experimental patch in comment #16 fixes it for me too. Owen, can you enlighten me on which way to go from here? get_font_metrics() apparently accesses the FT font directly for things that cairo doesn't tell us. Or maybe we shouls extend cairo metrics to include all the stuff we need in Pango font metrics? Finally, do you think I should commit that patch in the meanwhile?
Ok, I decided to go this way for now: I made pangofc-font not use is_hinted for any metric hinting. So I also removed the hack in pangoxft that forced is_hinted on. It still means that pangocairo is not using metrics reported by cairo, but that's another issue. I'm assuming that the ft2 backend was not depending on unhinted metrics for any real usecase. 2006-04-28 Behdad Esfahbod <behdad@gnome.org> * pango/pangofc-font.c (get_face_metrics), (pango_fc_font_get_raw_extents): Don't use is_hinted. Metrics are always hinted now. * pango/pangoxft-font.c (_pango_xft_font_new): Remove hack that forced is_hinted to TRUE.
Will this fix the width problems seen in hinted fonts, too? Or should I file another bug for that? Regardless, if this fixes it, well done guys! :)
I might be missing something, but I'm pretty positive this will break gnome-print, printing with cairo, etc. Unhinted metrics are needed. With cairo, the thing is that metric hinting and outline hinting can be turned on and off separately... The quick, right fix, I think would be to: A) Revert the last change B) Add, at the bottom of _pango_cairo_fc_font_new() // Override the default value computed from the pattern // property when we called g_object_new(). PANGO_FC_FONT(cffont)->is_hinted = cairo_font_options_get_hint_metrics(cffont->options) != CAIRO_HINT_METRICS_OFF); (CAIRO_HINT_METRICS_DEFAULT can't occur here ... the default value for the target surface has already been taken into account.) Setting the field is a little bit hacky ... you could add _pango_fc_font_set_is_hinted() for extra cleanliness, but I'm not really sure it improves things any.
Ok, I missed the point againm, that a device unit is not a dot but a point :(. I initially wanted to do what you suggest. The only problem is that setting the pattern property on an fcfont resets the is_hinted based on the hinting of the pattern. Should I remove that bit then, given that is_hinted is publicly accessible... I can add a public setter/getter pango_fc_font_set/get_hint_metrics. That actually makes it more useful I guess.
Setting the pattern of a PangoFcFont at any point other than g_object_new() is going to not work one bit... e.g., we don't drop an already loaded cairo font if we have one. The property is there basically so that I didn't need a separate pango_fc_font_initialize(), but could do the whole thing from the g_object_new() call, but really probably was a bad idea. I wouldn't add a public setter because whether to hint metrics is set via the Cairo font options, and it's not clear what should happen if what the user set something through the Pango API that was in in conflict with that. Yes, you can't individualyl control metric and outline hinting in PangoFT2 or PangoXft, but I don't see any reason to extend those APIs now. Plus, the user never really gets access to the PangoFcFont.
Thanks Owen. 2006-04-29 Behdad Esfahbod <behdad@gnome.org> Bug 307196 – Unhinted fonts are measured incorrectly and drawing problems occur as a result * pango/pangofc-font.c (get_face_metrics), (pango_fc_font_get_raw_extents): * pango/pangoxft-font.c (_pango_xft_font_new): Rollback previous change that forced metrics hinting always on. * pango/pangocairo-fcfont.c (_pango_cairo_fc_font_new): Set fcfont metrics hinting based on cairo font options.