discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Traditional Chinese partially supported


From: Yen-Ju Chen
Subject: RE: Traditional Chinese partially supported
Date: Tue, 12 Mar 2002 16:06:39 -0500

Hi,

  Here is a newer one.
  The iso10646-1 font always map to NSUnicodeStringEncoding.
  There is no font for NSUTF8StringEncoding, which use iso10646-1 font, too.
  So I change that in XftFontInfo and work out the NSUTF8StringEncoding in
NSStringDrawing.m.
  This can be done in GSFontInfo, too,
  but I don't know iso10646-1 font should be NSUnicodeStringEncoding or
NSUTF8StringEncoding.
  The result is the same, but the modification is less than previous one.
  The western language should be safe in this time, as least in front-end.

  I also modify the XIMInputServer to accept the Chinese XIM Server.
  The modification is ugly because there is some problems about
encoding/locale.
  Now, I can display and editing Chinese,
  but typing two Chinese characters will display only the first one in
NSTextView.
  There must be something wrong in Text system which is byte-based, not
character-based.
  It's hard to trace it because the Text system is too huge. :(

  Again, there is no copyright in these codes.
  Take the useful part and give me the suggestion for the wrong part.
  Thanx.

  Yen-Ju

  PS. Would it be better if the interface between XGGState and XftFontInfo
(and XGFontInfo)
         is unichar string or NSGlyph string based ?
         I means the draw: and widthOf:length: method in XftFontInfo.
         So if needed, a char string which pass throught DPSshow interface
can be
         convert back into unichar or NSGlyph string.
         The result would be:

         Front - end                DPS interface          Back-end
         unichar    => char   ------------------------> char == unichar
         NSGlyph => char    ------------------------> char ==>NSGlyph

         By this way, we can avoid the problem which casued by the DPS
interface
         and both front-end and back-end could be more glyph-based, not
byte-based.

> -----Original Message-----
> From: discuss-gnustep-admin@gnu.org
> [mailto:discuss-gnustep-admin@gnu.org]On Behalf Of Fred Kiefer
> Sent: Monday, March 11, 2002 5:45 PM
> To: Yen-Ju Chen
> Cc: discuss-gnustep@gnu.org
> Subject: Re: Traditional Chinese partially supported
>
>
> Hi,
>
> I like your efforts to support non-western fonts, but still they are
> wrong. What is wrong? Western languages are not all about ASCII, English
> is but not French, German or Norwegian.
> But you could get most of what you want, with even less changes! And
> also with out breaking any other language. I would prefere a different
> interface between the gui library and the back end, which will hopefully
> be accepted later on in the GNUstep community. Even with out that you
> could get your changes working. The basic idea is that drawing code will
> will always get the string encode to the font encoding. So if we
> specifiy UTF8 as the encoding for the XftFont, by setting
> mostCompatibleStringEncoding to NSUTF8StringEncoding in [XftFontInfo
> setupAttributes] and replacing the drawing methods as you did, we now
> only have to make sure that the String drawing code is sending over UTF8
> . This would work out, if we just replace the conversion function there.
>
>
> So we should take over your changes on GSFontInfo.m and check if the
> cutting off of the two first byte of a string should only happen if they
> are the Unicode sequence, but for the rest some rework is needed.
>
> Cheers Fred
>
>
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep

Attachment: gnustep-i18n-0.31.tar.gz
Description: GNU Zip compressed data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]