bug-gnustep
[Top][All Lists]
Advanced

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

Re: Full unicode support for back-xlib


From: Fred Kiefer
Subject: Re: Full unicode support for back-xlib
Date: Tue, 15 Jul 2003 11:52:19 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204

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






reply via email to

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