Re: Full unicode support for back-xlib

[Fred Kiefer]

Hi Kazu,

this is a nice patch you came up with. This should fill the gap between 
people only able to use basic X fonts and the ones with a XFT 
implementation (which also offers UTF8 support). As far as I know font 
sets are not restricted to XFree86 so this may be of help for more 
people out there using X Window systems without XFT.

As you by now will have noticed, the xlib backend comes along with its 
own XFT font class and I think that the font set support should be 
packaged up in a similar way. That is, a separate class in its own file 
that gets set as the default font class in [XGContext 
initializeBackend]. This allows even for a different way to list all the 
available font sets, if this is needed. And we don't need to fiddle with 
XGFont, ending up with a cleaner and smaller implementation.

This will on the other hand also show some of the limitations of the 
font sets. There are no character metric informations available for font 
sets, which was the reason I decided to give up on my own implementation 
based of font handling on top of them. Ok, I have to admitt, that this 
decission was European centric.

As for the comment in the dealloc method I am a bit worried. If this is 
true our current font handling is totally wrong. I cannot belive that we 
give up the reference to a font before we draw any text with it. Let us 
both try to dig deeper into this problem. It may just be a limitation of 
your current implementation.

As for your private UTF8 conversion function, I am not sure if this is 
needed or if GSFromUnicode() would do. This is restricted to only a part 
of the UTF range, but than again it is that part you may store in a 
NSString.

Cheers
Fred


Kazunobu Kuriyama wrote:
> Hi, all.
>
> Attached are the patches to make the xlib backend fully supports unicode.
> Accordingly, if the patches are applied, the backend should handle all 
> characters
> represented with NSGlyph.
>
> If the X Window System in use is already set up properly for your language
> environment (i.e., locale, fonts, an input method), GNUstep with back-xlib
> should work in cooperation with your native language only by setting the
> GNUSTEP_STRING_ENCODING to an appropriate value. For example, you can 
> browse
> and edit text files written in your native language with GNUstep 
> applications.
> (NOTE: This may not be true if a language in use is one of those in which
> text is drawn from right to left, such as Arabic or Hebrew. )
>
> The underlying window system must be XFree86 4.0.2 or higher to enable
> the new function provided by the patches.
>
> Moreover, to enable it, you need to pass -DUSE_MULITIBYTE to a compiler 
> when
> you build -back.  When this macro is not defined, the implementation
> reverts to the original.
>
> To ease this task, I prepared the patch for configure.ac. To use this, 
> go to
> the top directory of the source tree of -back, and do
>    $ cp configure.ac configurea.ac.orig
>    $ patch < configure.ac.patch
>    $ autoheader
>    $ autoconf
> Then you will find the new option --enable-multibyte in the newly generated
> configure script.  You can use this option to pass the above macro to a
> compiler automatically.
>
> The new configure script also checks if the underlying window system is
> XFree86 4.0.2 or higher if --enable-multibyte is specified.
>
> The patches were made against the corresponding files stored in the CVS
> repository of July 10.
>
> Any feedback is welcome.
>
> - KK