Subject: Re[2]: CJK patch test error report!
From: hashao (hashao@china.com)
Date: Mon Oct 30 2000 - 22:59:31 CST
Hello Vlad,
On Tuesday, October 31, 2000, Vlad Harchev wrote:
VH> On Mon, 30 Oct 2000, Belcon wrote:
>> problem:
>> * We still can't see any Chinese(GB2312) characters(unvisible) in frame;
>> If we open a GB2312 abw file,it just show blank letters(it is
>> two ASCII letters width)where it should show GB2312 characters.
>> If we select these Chinese characters although we can't see
>> them,and then select Menu item 'Find',and we will see Chinese
>> characters shown in box quite well.
VH> Could you please elaboraye - in which box - in input entry or the characters
VH> when highlighted in the document?
VH> Does it measure the width of Ch chars correctly (i.e. if you type English
VH> char, then Ch char, then English char - can Ch char fit between the English
VH> ones or not)?
The problem is in the usage of the function gdk_draw_text. GB (and ecuJP)
encoding is different from its fonts encoding which is in iso-2022.
To draw a EUC encoded GB char, you have to convert it to its font
encoding according to current locale and X11/locale/*/. Then the
function XDrawString16() can be called to draw the glyph.
EUC encoding starts from A1A1 while iso-2022 starts from 2121. So you
will get nothing by drawing a A1A1 in a iso-2022 encoded font.
This conversion is internally handled by X's I18N functions like
XmbDrawString(), XwcDrawString(). Gdk hides this further with its
gdk_draw_text() function, BTW, this is what was used in the cjk-patch
in file src/af/gr/unix/gr_UnixGraphics.cpp functions
GR_UnixGraphics::drawChar() and GR_UnixGraphics::drawChars().
For gdk_draw_text, if it is called with a single font, it will use
non-i18n functions XDrawString() and XDrawString16() without encoding
conversions. If the gdk_draw_text is called with a fontset, it will
use XmbDrawString which has the encoding conversion buildin.
See gdk source: gdk/gdkdraw.c
So one solution is to simple construct a fontset from EnglishFont and
ChineseFont, then draw the text by calling gdk_draw_text with the
fontset.
Another solution is to do the encoding conversion according to current
locale. Then draw things with the current logic.
P.S. There are no problem with BIG5 char because the encoding for
both BIG5 text and the fonts are the same. So no conversion is
needed.
-- Best regards, hashao mailto:hashao@china.com.n.s.pam
This archive was generated by hypermail 2b25 : Mon Oct 30 2000 - 22:59:41 CST