On May 29, 2004, Z <zleite(a)mminternet.com> wrote:
Now would you (or the list) happen to know why xorg does not follow
the
usual usual us_intl composition rules?
Err... Usual? If it's international, and some languages have
legitimate uses for ć, then it wouldn't be, erhm, international to map
'c to ç, would it?
So I would think xorg is doing the right thing in this regard, and so
is gtk. The difference is that gtk has custom compose rules for pt_BR
locales, and xorg doesn't.
The other difference is that the us-acentos keyboard layout, used for
the text console when US International configuration is selected, also
happens to generate ç from 'c. Nor surprising, since us-acentos was
created in Brazil, and never adjusted to match the improved (?) X11
Compose settings. Unfortunately, if this change was made, there'd be
no way (AFAICT) to generate ç in the text console. Oh well...
As it is now, gtk and, more
importantly, openoffice follow the old style.
?!?
I've just started OOo within a en_US.UTF-8 locale and US International
keyboard compose rules, and 'c does generate ć, like everywhere else.
Ditto if I start it as LANG=pt_BR.UTF-8 ooffice within my en_US.UTF-8
X session. This if FC2, BTW.
Also, how come the console won't show accented charachters on
en_US.UTF-8?
IIRC the text console is limited to 256-character fonts, so it can't
display full Unicode character sets. That's a shame, but I think this
limitation comes from the PC BIOS, so it's a bit hard to overcome
without going for bitmapped text consoles :-(
--
Alexandre Oliva
http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}