Re: 2-bytes character display ready ?

[Fred Kiefer]

Hi,

this time I am totally lost at what you are doing.

Yen-Ju Chen wrote:

>   After another try, I found I can show 2bytes character (Chinese) by only
> modified XGFont.m
>
>   This is the way I did.
>   1. Add a XFontSet in XGFontInfo declaration in XGContextPrivate.h file.
>   2. Initiate the XFontSet in  -initWithFontName of XGFont.m
>   3. In - drawString: and - draw: of XGFont.m,
>       use XmbDrawString instead XDrawString.
>       XmbDrawString need XFontSet to display correctly.

If you would be doing this, as I explained in the last mail, in another 
subclass of GSFontInfo that would be code we could actually include into 
the xgps back end. You might just start out on this, by coping the 
XGFont or the XftFontInfo files and changing the parts you need.

>   That's all. I don't need to modify any source code in gui and DPSxxx()
> anymore.
>   So the question is: How do I know the encoding of a string (char*) ?

Now way you can tell. Any C string can include all characters from 
0-255, and even if some are not used this is only an indication that 
they are not used, not that they are not allowed. So the actual encoding 
is some additional information that must go along with the string. 
GNUstep therefor mostly uses Unicode strings or strings that are in the 
well defined default encoding (set up by an environment variable). All 
strings get converted to a suitable encoding for the font, before being 
send over to the back end. This is done in the NSStringDrawing code in 
gui, where we use the [NSFont mostCompatibleStringEncoding]. As the 
comment there explains this will only work out for 8-Bit encodings, so I 
don't quite get, how it should work for your font.

>   I test NSTextField and NSButton,
>   and only -draw: in XGFont.m is used for NSTextField and NSButton.
>   But -draw: use char*, not NSString.
>   Therefore, I can't tell which encoding it is.

Once again, the only method to draw a string in GNUstep is DPSshow(), 
which is currently used mostly from NSStringDrawing, so that if we ever 
extend or replace this interface, we will only have to change one place. 
The additional method I put into XGFont is just there to experiment with 
a different way to do things. Not even I think that this is the way to go.


>   The reason that most i18n softwares use XmbDrawString instead
> XDrawString16
>   is because people always mix 1bytes and 2bytes character in their
> language.
>   When they input 2bytes character (native language),
>   the software need use 2bytes font.
>   When they input english, western language or number,
>   the software need use 1bytes font (because 2byte font is ugly for 1byes
> character).
>   I think that's the reason they use XFontSet to solve the problem of
> switching fonts.
>   But as Fred said, XFontSet doesn't give a rang of information.
>
>   Maybe Xft will support 2bytes character better then Xlib.
>   I will try to use Xft later.
>   When I use Xft in backend (anti-alias), the Ink.app can find all Chinese
> fonts,
>   but XGFont fails to find Chinese fonts.
>
>   The reason I would like to add 2bytes support in either XGFont or
> XftFontInfo
>   is that as I said above, people always use 1bytes and 2bytes at the same
> time,
>   depending what kind of  character they type.
>   Make another XGFont support is not a usual way I know.

As for the XFontSet I don't know how this helps you much. It should 
still keep you stuck with about 255 characters, which is a lot better 
than having non at all, but still no solution. (given that we introduce 
that other interface between gui and the back ends, that Richard is now 
trying to define, font set would be very useful, as they provide 
different encodings for the same abstract font at the same time, there 
by giving a much richer range to choose from)

Cheers
Fred