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)
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"
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
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
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_half_width : see Unicode TR #11)
and two accessor functions to retrieve them.
Applying either Anthony's patch for Xft
mentioned in the email linked
above or the patch at
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
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_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.
> 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
I'll comment on is-dual-width on bug 108728.