X locale handling (was: Re: gtk+)

[Andrzej Krzysztofowicz]

=?iso-8859-2?Q?Pawe=B3?= Sakowski wrote:
> On Thu, 2004-09-23 at 09:49 +0200, Andrzej Krzysztofowicz wrote:
> 
> > Are there (IYO) any objections against syncing the locale.alias from X with
> > the glibc encodings? Any new problems expected?
> 
> I don't expect any new problems, but neither will it fix the old one. It
> might do the job for some typical cases (like et_EE you mentioned
> earlier), but it won't sort out the test case above.
> 
> > But en_US.UTF-8/XLC_LOCALE does not refer to many fonts, possibly not being
> > able to display characters in many languages (different kinds of cyrillic,
> > devanagari, arabic, lao, armenian, georgian, etc.).
> > I don't know what I can break adding more fsN/csN sections there.
> 
> I don't know how that works..

It defines font of which registry/encoding to use with specific locale, and
what is the prefered sequence.
They are generally defined on locale basis, bux except UTF.
Eg. ja_JP/UTF prefers kanji fonts over iso fonts, while en_US/utf has
reversed preference.
And current UTF locale never try to use Georgian/Armenian/non KOI8-R cyrillic
fonts, for example.

> I was trying to do something else: to strip all cognition of charset out
> of locale.alias and make X retrieve that information via
> nl_langinfo(CODESET). The problem is that libX11 is a big chunk of
> obscure code and it's pretty much undebuggable. Hopefully I'll stay
> motivated for long enough to get sensible results.

May be problem for UTF, as shown above.

And I have no idea which fonts should be used for ISO-8859-16 locale
(Romanian prefers it AFAIK). There's no iso8859-16 font...

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry at mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology