On Tue, 2004-05-25 at 08:17, Alexandre Oliva wrote: > Well, Ä surely exists in some languages, and you have to agree that it > would be damn surprising if Ä were to prefer Ä over Ã. Why the heck > is the acute accent *under* the letter, one would think... > > If your locale is pt (or pt_BR?), gtk apps will map 'c to Ã, but X > will still compose 'c into Ä. That's bad, and inconsistent. The > solution (untested) is to create a file in > /usr/lib/X11/locale/pt_BR.UTF-8/Compose, adapted from > /usr/lib/X11/locale/en_US.UTF-8/Compose, in which the combinations of > <dead_acute> and <c> or <C> are mapped to the à and à characters, > instead of Ä and Ä as they are. Then adjust compose.dir in the parent > directory such that pt_BR.UTF-8 is mapped to this new Compose rules. > > As far as I can tell you're mistaken. From personal experience, FC1 > (and probably RHL9) worked just the same in this regard, at least as > far as X11 is concerned. I haven't checked for changes in gtk within > pt_BR locales, though; this might have changed. Maybe you had > different i18n settings. For example, switching from ISO-8859-1 to > UTF-8, or from pt_BR to en_US would have changed the 'c compose rules > on at least some applications. Actually, you're right on all counts. I'm using en_US.UTF-8, but I write a lot in portuguese (I'm brazilian too). I was using en_US before. Now would you (or the list) happen to know why xorg does not follow the usual usual us_intl composition rules? As it is now, gtk and, more importantly, openoffice follow the old style. Is there a standard? Also, how come the console won't show accented charachters on en_US.UTF-8? In the meantime I'll probably patch en_US.UTF-8/Compose to be consistent with gtk, so my users won't complain...
