After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 106624 - Sample string approach to approximate_char_width and CJK
Sample string approach to approximate_char_width and CJK
Status: RESOLVED WONTFIX
Product: pango
Classification: Platform
Component: general
1.1.x
Other Linux
: Normal normal
: 1.4 API freeze
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2003-02-20 17:51 UTC by Jungshik Shin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jungshik Shin 2003-02-20 17:51:13 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.
Comment 1 Jungshik Shin 2003-02-21 08:55:15 UTC
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. 


Comment 2 Jungshik Shin 2003-02-21 14:46:01 UTC
> 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. 
Comment 3 Jungshik Shin 2003-02-22 14:10:08 UTC
> 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. 

Comment 4 Owen Taylor 2003-05-27 16:30:19 UTC
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?
Comment 5 Jungshik Shin 2003-05-30 07:48:42 UTC
> 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? 
Comment 6 Owen Taylor 2003-08-25 13:54:29 UTC
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.
Comment 7 Noah Levitt 2003-11-25 18:26:57 UTC
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.)
Comment 8 Owen Taylor 2004-02-21 17:49:34 UTC
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.