On May 29, 2004, Z <zleite@xxxxxxxxxxxxxx> 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@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}