Created attachment 93372 [details]
Screenshot of the bug description text, to avoid bad charset conversion

Created attachment 93373 [details]
OpenOffice-created bug text

Try compose (= right-alt) comma c.  This works for me, with a us-intl keyboard
configuration in X, but on Shrike.  I'm afraid I don't remember whether keymap
fixes to enable this sequence made it to 8.0.  It's been a while.

I just remembered that I have RPMS for 8.0 that introduce ',c as a sequence to
generate ç, but they're significnatly outdated now (e.g., they certainly don't
include any recent bug-fixes in the XFree86 pakcages).  You may still get the
RPMS, SRPMS and the patch for the spec file, in case you decide to merge the
fixes into a newer SRPM, in ftp://people.redhat.com/aoliva/8.0.

On RH8, I tried right-alt+'+c and got "¢". Actually the "'" is not needed to make this char. 
On caps I got the copyright sign: © 
 
The compatible, lets say "correct", way to make the ç char is with "'" + c. 
On RH9 how the cedilla char can be generated? 
 
Thank you, 
Avi 
 

comma is , not '.  Try Right-alt , c.  Or maybe your compose character is mapped
to something other than right-alt?  Or maybe you're not using a keyboard
configuration that has a compose key.  

Anyway, using 'c for ç was a mistake, since there are languages that use the Ä
character, and UTF8 is an encoding that is meant to support all languages. 
Favoring Portuguese over Czech didn't feel right.  This was mistake was fixed in
some version of XFree86 (4.2?), that was adopted in Red Hat Linux 8.0 (IIRC).

My personal recommendation is to use the us_intl keymap if you have a us
keyboard, then the sequence compose ,, will generate ¸ (cedilla), and compose ,c
will generate ç (c-cedilla); if you have abnt-2 you already have a ç key.  I
actually use the gnome keyboard layout switcher to switch between a US and a
US-intl configuration, such that, with a keystroke like Super-Shift (Super is
the Windows-logo key), I can enable or disable compose rules and dead accents. 
IIRC KDE has something similar.

Would this setup work for you?

I'm using US-International configuration.
I made it happen on RH8 with the compose key.
But in another machine with RH9 it didn't worked.

In addition, I discovered something new: Can't create the '"' (aspas) char. 
Using compose or shift, makes appear '¨' (trema) char.

This last update is on a RH9 installation.

Compose (Right-Alt) Shift ' should generate " in a us-intl keyboard.  There was
a patch for XFree86 that changed the UTF8 compose rules such that Shift ' blank
would generate it as well, but the changes were considered too risky for Shrike,
so we left them out.  They made it to Severn, though.  At some point Mike
suggested we might offer the patched UTF8 Compose rules as a file in
/usr/share/doc or so, but I can't find anything like that atm.  Mike, did we
carry that plan out, or does one have to actually rebuild the XFree86 RPMS after
removing the Compose rules patch from the spec file to get the new compose rules
enabled?

Oops, I take that part of what I just wrote back.  " space doesn't generate a "
with X applications (say xterm or GNU Emacs), only in GTK applications (gtk uses
its own rules).

I'm working on some schools to deliver Linux labs to the students.
It is being very hard to find and explain this extra-terrestrial composition 
keys to them, specially when they are used to Windows.
This is bad for cultural user migration.

I think RH should look for Windows compatible keymaps. US-International keymaps 
on Linux should be identical to US-International keymaps on Linux. This is waht 
people are used to. UTF-8 is solving many problems but are creating others that 
may be bigger, specially when related to Windows migration.

Red Hat does not maintain nor have the resources to maintain a separate fork
of the XFree86 keymap file databases and other related files.  It is critically
important that there is one official master database, which is authoritative,
and which Red Hat, and all other distributions and OS's out there use.  That
official place is XFree86.org.  The experts in the xkb area are all at
XFree86.org as well, in particular Ivan Pascal, and Ivan as well as others
incorporate xkb changes into XFree86 CVS very quickly, and discuss reported
bugs and requests also very quickly.

The best place for any changes to xkb and related i18n files is thus at
XFree86.org, and not at Red Hat.  The changes get dealt with and/or included
at XFree86.org as reported rather quickly, and the experts in this area are
located there.  This provides Red Hat and other distributions with a central
area to get speedy changes to xkb from, and ensures cross OS and distribution
similarities.

Any discussion of making any major changes to xkb should be done at XFree86.org
on it's mailing lists.  Red Hat, like all other vendors, is going to follow
the official standard, and that standard is currently what ships with XFree86.
In general, I will not apply any xkb related patches, until someone has
submitted their suggestions/requests directly to XFree86.org via their bugzilla
located at http://bugs.xfree86.org and the changes requested have been commited
into the XFree86 development CVS repository and are deemed complete and safe
for inclusion in the existing product or erratum.  This is important both for
quality control, and for standardization and consistency.


Re: UTF-8

If you're refering to Red Hat Linux's change to use UTF-8 by default in
Red Hat Linux 8.0 everywhere, this change was made with an incredible amount
of thought, and the decision to use UTF-8 was unanimous that it was the best
thing to do and the right time to do it.  UTF-8 has been common in the Windows
using world since 1995, and is very important in the future of Linux.  The
sooner the changeover was made, the better for all multilingual users.

A bugzilla bug report against XFree86 is not however the proper forum to
debate that or discuss that though, so I won't get into further detail.
You may wish to search Red Hat mailing list archives for similar discussions
however which may provide the answers you're looking for, or to post a
question about UTF-8 there, and someone will likely go into greater detail.

Hope this helps.

Alex:  The changes you mention, which were disabled for Shrike due to being
considered a risk, I had planned on enabling in rawhide ASAP after shrike's
release, and up until today, I thought they were in fact disabled.  I just
checked a while ago however, and the 2 patches were still being applied,
giving the Shrike behaviour.  I've disabled the 2 patches now, and the next
build of 4.3.0-20 will contain this change.

I'm assuming that this new build will fix the problem described in this report
and setting the status to MODIFIED.  Once one of you has had the chance to
test this, please set the status to RAWHIDE if the problem is resolved now,
or set it back to ASSIGNED otherwise.  If the problem does persist, please
report the issue at http://bugs.xfree86.org if it isn't already, and please
include the upstream bug URL so that I can track XFree86.org's official
response and try to make our standard release compatible with their current
bits, backporting bugfixes if possible.

Thanks in advance guys.

Regarding the keymaps, I created the bug 608 in http://bugs.xfree86.org.

Regarding UTF-8, I don't know why everybody says Windows is UTF-8 or any 
Unicode. In any brazilian protugues Windows installation I saw or installed 
(XP, 2k, 9x), text files and filenames are always Latin1. In fact, I could 
never make a Windows machine work on any Unicode mode (only Internet Explorer 
when the web page explicitly asks for it in the header). And I can tell you I 
have spent some time trying to do specifically this configuration, without 
success.

Mike, in order to fix the `aspas' (quotedbl) problem, we need the patch I
mentioned in that other bug, that made it to XFree86 CVS after the 4.3.0
release.  I hope it made it to 4.3.0-20, otherwise, would you please start
another build with that patch in?

*** This bug has been marked as a duplicate of 80244 ***

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.