The return of the acute-cedilla problem

[Z]

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...