=?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 [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Gdansk University of Technology _______________________________________________ pld-devel-en mailing list [EMAIL PROTECTED] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
