(I still have some difficulty sending mails.)
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> wrote:
> Could you factor out this part of the patch?
> Then we can look at it, and if it looks good, apply it to cvs.
I will try. But please wait!
> So the font selection is based on the global LC_CTYPE?
>
> Hmm, that seems a bit restrictive. Is it not possible to specifically
> ask for the font norms for a given locale without setting LC_CTYPE?
Only if you are ready to use a semi-internal Xlib function _XOpenLC().
There are no public interfaces in Xlib to access its powerful Input/Output
methods machinery without setting locale. If it is allowed to use
_XOpenLC(), then an X client can manage multiple locales IM/OM at
the same time.
> That would probably be the best solution, since we would like to
> support writing Japanese on a system where the LC_CTYPE might be
> set up for Danish.
>
> If we assume that it is possible to specify our own LC_CTYPE without
> really doing it (you know what I mean), how would this fit in with
> Dekel's approach? Dekel, can the two approaches be integrated in
> some way?
Well, I'm not against to have a unicode based multilingual document
support. I would just like to have a mode for single language
documents in local encodings, just as single byte language users
have at present.
[EMAIL PROTECTED] (Lars Gullik Bj nes) wrote:
> Regardless of how it ends up: we don't want multi-byte charates as the
> internal representation. We also want to support multiple languages on
> the same time, afaik unicode is the road to accomplish this.
I perfectly understand we do not want to use variable length multibyte
characters as the internal representation. But any multibyte encodings
have their fixed width wide charcater representation counterpart. So
for a single language document, unicode *encoding* might not be
obligatory.
Regards,
SMiyata
