GNOME Bugzilla – Bug 314114
max_x_advance not appropriate for approximate_(char|digit)_width
Last modified: 2006-05-21 23:32:55 UTC
pango/pangocairo-win32font.c(pango_cairo_win32_font_get_metrics) initializes the pango font metrics from cairo font metrics like this : cwfont->metrics->approximate_char_width = font_extents.max_x_advance * PANGO_SCALE; cwfont->metrics->approximate_digit_width = font_extents.max_x_advance * PANGO_SCALE; cairo/src/cairo-win32-font.c(_cairo_win32_scaled_font_font_extents) intialize max_x_advance from TEXTMETRIC::tmMaxCharWidth which causes a far too huge appearence of Gtk widgets which take approximate_*_width into account. These are at least GtkColorSelection and GtkFileChooser but probably many more. With my default gtk font tmMaxCharWidth is about three times tmAveCharWidth. Probably PangoCairoWin32 should calculate the approximate widths from sample strings - like the other pango backends do. But I'm a little bit uncertain how this should look like, e.g. which HDC to use.
Created attachment 51074 [details] the visual effect of the bug
Created attachment 51077 [details] how it should look like to get a grip on the bug I've hacked _cairo_win32_scaled_font_font_extents() like this. Obviously not the right fix but the result looks right ;) //extents->max_x_advance = metrics.tmMaxCharWidth / scaled_font->logical_scale; extents->max_x_advance = metrics.tmAveCharWidth / scaled_font->logical_scale;
*** Bug 314580 has been marked as a duplicate of this bug. ***
Fixed in HEAD and pango-1-10: 2005-09-14 Tor Lillqvist <tml@novell.com> * pango/pangocairo-win32font.c (struct _PangoCairoWin32Font): Have a list of metrics by language instead of just one metrics. (pango_cairo_win32_font_get_scaled_font): Use the name cwfont instead of cffont. (free_metrics_info, pango_cairo_win32_font_finalize): Free the metrics by language list. (create_metrics_for_context): New helper function. Approximate the character and digit widths correctly. (#314114) (pango_cairo_win32_font_get_metrics): Use the list of metrics by language. Call create_metrics_for_context() to measure metrics. (_pango_cairo_win32_font_new): Keep the PangoWin32Font objects in the PangoWin32Face::cached_fonts, like the pangowin32 backend does. PangoWin32Face::cached_fonts isn't really a proper cache. It's a list with unbound length, one PangoWin32Font per size. Once there is cacheing in cairo this can be dropped presumably? What does the pangofc backend do? There are too many levels of cacheing going on: we have the stuff in pangowin32-fontcache.c (unused now with cairo), the PangoWin32FontMap::freed_fonts cache, and the PangoWin32::cached_fonts list. * pango/pangowin32-fontmap.c (pango_win32_fontmap_cache_remove, pango_win32_fontmap_cache_clear): Use GQueue API instead of manipulating pointers manually. * pango/pangowin32-private.h * pango/pangowin32.c: Move PangoWin32MetricsInfo to the private header file, as also pangocairo-win32font.c uses it.
Created attachment 61756 [details] Entries in gtk+-2.6 ok
Created attachment 61757 [details] entries in gtk+-2.8 not ok
Hi Tor, my bug (314580) was marked as duplicate, but after make the tests, I see that the bug is not solved. The first picture show a dialog compiled and run with gtk+-2.6 and all entries are ok. We set the length of the entry with gtk_entry_set_width_chars to 20. The second picture show the same source compile and run with gtk+-2.8 (glib 2.10.1, gtk+-2.8.15, cairo 1.0.4, pango 1.12.0). The font is Courier Bold 10. Thanks for your help. Bernd Demian
Created attachment 65764 [details] C Testfile und resourcen file to demonstrate the bug When you run the test app under gtk 2.8 you see, that the length does not match. May be we make a mistake, please tell as. For us the failure is a showstopper, we can't send a new app to a customer, so we need your help. MfG bernd
Please attach sample programs as simple separate source code files as such. (And gtkrc or other extra files separately.) No executables, tarballs, zipfiles, etc. It's in the bug reporter's own interest, as it's just extra work to unpack such tarballs, which can be the needle that breaks the camel's back, i.e. means that a maintainer thinks, "oh well, won't bother with this right now"...
This is another bug now, that I filed as bug 342525. *** This bug has been marked as a duplicate of 342525 ***
I am not sure this is a duplicate of bug #342525, as that talks about the approximate digit width, and the test program here calls gtk_entry_set_width_chars(), which uses the average char width. I am not sure this is a real bug, though, as the average char width is just a somewhat wild guess, based on a (language-dependent) sample string that contains all kinds of letters, not just digits. I think that if you want an entry box that you can be reasonably sure is exactly the correct width for n digits, you will have to first set n digits into a pango layout (using the same font) and check its size, then set the entry box's width to that. Would this work?
Hmm, on the other hand you *are* using a fixed-width font here, so one would think the metrics calculations would be a bit more exact. Debugging...
Nah, Behdad is right, this is a cross-platform problem, now known as bug #342529. *** This bug has been marked as a duplicate of 342529 ***