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