GNOME Bugzilla – Bug 106624
Sample string approach to approximate_char_width and CJK
Last modified: 2004-12-22 21:47:04 UTC
The following is an excerpt from Anthony Fok's email to fonts@xfree86 list. (for details see bug 106618) <quote> There are quite a few modern CJK TrueType fonts with the "fixedPitch" flag set to "true" to mean that: * All CJK glyphs have the same "fullwidth" * The ASCII glyphs and other special glyphs have the same "halfwidth" </quote> Currently, when font metrics for one of these fonts is stored in pango_font_metrics, pango_font_metrics_get_approximate_char_width() and ..._digit_width() returns the same value, the width of 'full width' characters although the width of digits (if we can restrict digits to those 10 in [U+0030, U+0039]) in these fonts is exactly the half the width of the majority of characters in those fonts(CJK characters). I'm not sure what the best way to deal with this is... One is to do nothing leaving things up to upstream libraries like Xft/freetype/fc/etc and application developers (as done by gnome-terminal- although not successful, and vim-gtk2) Other possibilities include: - make ....digit_width() returns exactly half the return value of ....char_width() for 'fixed-width' CJK fonts - add two new fields to PangoFontMetrics struct (approximate_east_asian_full_width, approximate_east_asian_half_width : see Unicode TR #11) and two accessor functions to retrieve them.
http://www.mail-archive.com/fonts@xfree86.org/msg01375.html Applying either Anthony's patch for Xft mentioned in the email linked above or the patch at http://www.kde.gr.jp/~akito/patch/fcpackage/2_1/ would solve the problem of pango_...metrics_..digit_width and .._char_width returning the same value for CJK 'fixed' width(bi-width) fonts. I'm aware that they're approximate, but it seems not right to return twice the width when all digits are of equal width. Anyway, Xft needs to be fixed for this issue. Nonetheless, PangoFontMetric or PangoFontDescription may need to be extended to indicate 'spacing properties' of an 'abstract' pango font.
> solve the problem of pango_...metrics_..digit_width > and .._char_width returning the same value for > CJK 'fixed' width(bi-width) fonts. Applying Anthony's patch solved the problem as expected and programs like vim with gtk2 works fine with CJK 'fixed width' font.
> add two new fields to PangoFontMetrics struct > (approximate_east_asian_full_width, > approximate_east_asian_half_width : see Unicode TR #11) > and two accessor functions to retrieve them. To do this, there needs to be LangInfo lang_text_cjk[] or sth. like that in pango-utils.c in addition to lang_text[]. lang_text_cjk[] has to be made of 'pure full-width CJK' strings instead of CJK + US-ASCII (mixed width) strings.
digit_width() is computed from the width of the ASCII characters 0123456789, so if it is returning the wrong thing, that sounds like simply an Xft bug ... Xft is actually spacing out the digits inappropriately,and nothing to do with Pango. No?
> Xft is actually spacing out the digits > inappropriately,and nothing to do with Pango. It's not just Xft but freetype2/fontconfig/Xft. Anyway, if you don't want to implement a workaround for old versions of freetype2/fc/Xft(the bug was fixed very recently) as was done in Vim-gtk2, gnome-terminal and xterm, that's up to you. > PangoFontMetric or PangoFontDescription > may need to be extended to indicate 'spacing properties' > of an 'abstract' pango font. There's still something Pango has to do about those CJK 'fixed-width'(dual-width/bi-width) fonts. Does Pango return those fonts when requested for 'monospace' fonts? If it does, how does it calculate advance-widths for glyphs in those fonts?
We probably need to make the sample strings for CJK languages all double width characters. pango_font_metrics_get_dual_width() might make sense too, though it's not entirely clear to me that any programs need to treat dual-width fonts any different from monospace fonts. I suppose one thing is that for dual-width fonts, approximate_char_width is twice the grid size, not the grid size. Pango doesn't currently even have a "is_monospaced" API - see bug 108728.
I'm not sure this is needed at all once the is_monospace patch is committed. People can use approximate_digit_width to get the grid size, the way Jungshik tried at first, since Xft works now. Then they can double it for the CJK size. (Whether there should be is_dual_width is a separate question.)
Hmm, we can't change get_sample_string to be only full-width, since that will screw up the vertical metrics for the case where we are actually mixing different fonts for ASCII and non-ASCII. I'll comment on is-dual-width on bug 108728.