Re: Full unicode support for back-xlib

[Kazunobu Kuriyama]

Fred Kiefer wrote:

>
> 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.

Good idea.  Then I need to define a new subclass of GSFontInfo and use
it in [XGContext initializeBackend], right?

>
> 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.

That's why I made the compilation switch USE_MULTIBYTE.  Rather, I
should put your point of view in my mind because the implementation
might fail to handle characters other than European and East Asian ones.
For such characters, font metrics may play an essential role to
align strings.

>
> 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.

Because the X server does not necessarily handle events syncronously, it
is possible for a method/procedure to return before the server has
processed a given  event.  If this holds true and the stack which holds
the parameter(s) of a method/procedure has already gone, it is likely to
result in segmentation fault. Also, by very nature of this phenomenon,
it is hard to replicate it, thus preventing people from report it as a bug.

On the other hand, XSync() did not fix the problem (Rather, XSync()
looked as if it didn't work).  So it is quite possible that I'm wrong.
So I should check it by myself again before I ask you for something.

>
> 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.

I'll check it and replace the conversion function with GSFromUnicode()
if necessary.

Thank you, Fred.

Cheers,
- Kazu