SOURCES: X11-glibc-charset.patch (NEW) - patch to use

Andrzej Krzysztofowicz ankry at green.mif.pg.gda.pl
Mon Sep 27 02:34:01 CEST 2004


=?iso-8859-2?Q?Pawe=B3?= Sakowski wrote:
> On Sun, 2004-09-26 at 11:15 +0200, Andrzej Krzysztofowicz wrote:
> > What about *.ISO-8859-16 locales, which seem to be unsupported by X at the
> > moment? Do we need to prepare iso-16 fonts to support them?
> 
> Probably it'll take writing /usr/X11R6/lib/locale/iso8859-16/* and maybe
> creating 8-bit ISO-8859-16 fonts. Anyway, adding iso*16 support to X11
> is way beyond the extent of my patch.

So I'll not duplicate your work.
But I want to port it to XFree.

> > > ++/* Substitute aa_BB[.CC][@dd] with aa_BB.`locale charmap`[@dd] */
> > 
> > Some default glibc locale charmaps are unsupported by X, eg. tg_TJ.KOI8-T.
> > Also zh_CN.GB18030 (but this is not the default one). What do you suggest?
> 
> Same thing as with iso*16: if tg_TJ.KOI8-T isn't supported by vanilla

Hmmm, but tg_TJ.KOI8-C _is_ supported by X and KOI8-C is not so different
from KOI8-T. So maybe mapping "tg_TJ" to not-fully-compatible locale here is
not so bad as making it fully unsupported.
Porting KOI8-T to X may be easy but non-existent KOI8-T fonts may be a
problem.

BTW, I'll work on porting TATAR-CYR to glibc to make comatibility with X fot
tt_RU possible.

> X11, neither will tg_TJ with my patch. It'll make you get the "locale
> not supported by Xlib" message in either case. Changing that will
> require a fair amount of work.
> 
> A special case I can easily support is when X supports a charset under a
> different name than glibc's. I already do it for ISO 8859.
> 
> A perfect solution would be to strip all cognition of charset from X and
> use glibc's features of charset manipulation (UTF-8<=>locale conversion
> should suffice) and use fonts basing on what characters they provide,
> not on what encoding(s) they declare to support. But this would imply
> rewriting major parts of libX11.
> 
> > Some other locale to work need X locale definition fixes. I tried to do some
> > sync for X locale, basing on the glibc one. The files ara available at
> > http://fly.mif.pg.gda.pl/X/
> > I do not support patches as they would be bigger and more difficult to
> > maintain (~70% of files is modified).
> 
> It's for the very same reason that I'm modifying locale.alias with sed
> +awk. If you're able to express your changes as a relatively simple
> script, feel free to apply them in X11.spec

I'm adding a lot of encodings from glibc, which did not exist in X earlier.
And adding mapping of some glibc aliases, eg:
- glibc does not understand de_DE.ISO-8859-15 (unlike X)
- X does not understand de_DE.ISO-8859-15 at euro (unlike glibc)
And removing unnecessary first parts (mappings definition with no ":", they
seem to be obsolete).

> > I assume you do notice the difference in handling some UTF locales by X
> > locale, eg. for pl_PL.UTF-8 and ko_KR.UTF-8 ...
> 
> No, I haven't noticed any differences. And there definitely shouldn't be
> any (unless they're for the better :). What have you noticed?

Different sequence in prefered font used (eg. for ko_KR.UTF-8 the ISO10646
fonts are the last, while for en_US.UTF-8 are the first).
Sometimes more or less font encodings are being attempted to try.

Look at the appropriate XLC_LOCALE files carefully.

I think it would be better to leave the differences (maybe new definition
will appear in future) for lower memory consuming (but I'm not absolutely
sure of it).

Moreover, some characters will probably be never properly displayed in
*.UTF-8 locales as encodings used for them are not mentioned in appropriate
XLC_LOCALE files (eg. Georgian, Armenian, Lao, Tibetan).

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




More information about the pld-devel-en mailing list