Bug 76248

I realize now that I am reading my bug description report, that in a number of
places I entered the "c-cedilla" character it was bugzilla-ically translated
into a "g".  Ugh.

Anyway, I hope it is clear what I meant.  "c-cedilla" is the "c" with a short
tai sticking out of the bottom.  Type apostrophy followed by "c" (when you
LANG=en_US and keyboard is "us_intl") to see what I mean.

I'm assuming this is a gkb_applet problem, but I'm not sure really.

Having LANG=en_US.UTF-8 also distorts man pages and ncurses-based menus (at 
least I've noticed this when logged in via SSH).  I manually changed it back to 
LANG=en_US in /etc/sysconfig/i18n and all is well.

There is more on this and it is recent, I mean it did not happen to me with the
original RH 8.0 installation... perhaps some recent update I did't notice?
I have LANG=en_US.UTF-8 but pt-latin1 keyboard:
c-cedilla , small ordinal (ordfeminine and masculine) and keys accessed with
alt_gr  (including brakets and 'at' sign) stop working in KDE (but not in text
mode console)

hp-

Just noticed your comments, I must have missed the bugzilla email when you
originally made them.

I do not believe this is a gkb_applet problem.  You should be able to reproduce
by logging out and changing the language using gdm.  I simply used gkb_applet as
a shortcut to having to log out constantly to reproduce the problem.  Choosing
"english" in gdm sets LANG=en_US.UTF-8 (exhibiting the accented characters
problem), while selecting "system default" in gdm sets LANG=en_US (does not
exhibit the accented characters problem).

I chose "gnome-applets" for the component of this bug only because I didn't know
what else to choose.  Is there a better component?

Thanks

BTW, there is another bug that seems to be related to problems with LANG=en_US.UTF-8

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77045

... which is also resolved by changing LANG.

So essentially the us_intl keymap works in en_US[.ISO88591] but not 
en_US.UTF-8. (We should be sure this is general across Qt, GTK, etc. apps
and not only OpenOffice.)

I would tend to reassign to XFree86, if it applies to all applications
and appears to be a bug in either the keymap or X's interpretation of the keymap.

I found that (at least in my case) what was causing all the problems was simply
a corrupt file: /etc/X11/xkb/types/iso9995 has became dirty after a forced fsck
and that is what caused the sudden problem I didn't originally had.
I have LANG=en_US.UTF-8 and pt-latin1 and I can (now, again) obtain c-cedilla
directly in my keyb (I do not need to use the Keyboard Layout Switcher).
Sorry fellows, this was not the same problem.

Here is a list of applications on a standard RH8.0 installation that exhibit
this bug.  I was unable to test KDE since I don't install it.

dia - problem
gnome-terminal - okay
abiword - problem
gedit - okay
vim (text mode) - okay
emacs (text mode) - okay
emacs (X mode) - problem
mozilla - problem
gnumeric - problem
nedit - problem
balsa - problem
gFTP - problem
gdm setup - okay
gqview - problem
dictionary - okay
file roller - okay

<mode type="talking out ass">
So, maybe the only apps that work correctly are the ones ported to gnome2?
</mode>

HTH, Jon

Adding CC to see if anyone has a clue.

What happens if you open up a terminal, and set the keyboard to us_intl
manually via setxkbmap?

The "problem" here is pretty straightforward ... C with acute accent
exists and is used in various eastern-European languages, 
 
 en_US.iso-8859-1 doesn't have this character so dead_acute + c might
   as well give c_cedilla

 en_US.UTF-8 does have this character, so the compose tables for it
  give this character instead of c_cedilla.

It's not a keyboard map issue at all, but rather a compose table issue.
Therefore, we can't do anything special when the keyboard map is
us_intl, even if we know that us_intl is used mostly in Brazilian,
and thus needs c-cedilla not c-with-acute.

(Sadly, I think you'll find the gtk2 packages in Rawhide cause the "OK"
applications above to give the same behavior as the rest ... the c-with-acute
combination was added recently.)

About all that can be done here is to create a special pt_BR.UTF-8 compose
table; people who want english messages plus the pt_BR compose table
will need to use a mixed setup like "LANG=pt_BR.UTF-8 LC_MESSAGES=en_US.UTF-8"

Owen-

What you are saying makes sense.  I didn't know that "c acute" existed anywhere.  

For me, even though I live in Brasil, 99% of the time I use LANG=en_US.whatever
and a US keyboard because it is the easiest combination in which to do computer
programming.  But, I need a quick way to switch to being able to type Portuguese
(including c_cedilla) for email, etc.  I imagine this is a fairly common
situation for people.

Crazy idea.  If you think about it, making c_cedilla by pressing "apostrophy c"
seems kind of counter intuitive since the tail in the c_cedilla goes down. 
Obviously the comma couldn't be used (since it is a popular key), but what about
using "semi-colon c" to mean c_cedilla?  Would that solve the problem?

I smell a keyboard mappings holy war...   :)

In any case, looks like it's definitely not a gnome-applets issue.

Probably not a gnome-applets issue, but it isn't really a Red Hat Linux
specific issue either IMHO.  This type of a change is something that
ultimately needs to be changed in the upstream XFree86 source code itself
if it is indeed a feature that should be part of any vendor's system, and
should not be a Red Hat specific or any other vendor specific thing.

I think it is best if you report this issue to the XFree86 team directly
by posting a discussion about it on the xpert mailing list and
soliciting the opinions of many other users and developers.  Once a
conclusion is reached, if the XFree86 team hasn't already commited something
to the CVS repository to add such an enhancement, you might want to post
a summary of the discussion as a bug report to xfree86.

XFree86org has shown a distinct heightened interest in internationalization
issues lately, in particular with respect to xkb changes and similar, and
having this flow through the upstream channel is much more likely to have a
speedier resolution.

I'm closing this for now as DEFERED for upstream resolution.  Once upstream
discussion and resolution has taken place, please reopen this report with
the results once changes have been commited to CVS to handle this, and I'll
build new packages in RAWHIDE.

Thanks.

I think we missed an important information from post #4 :
>>keys accessed with alt_gr  (including brakets and 'at' sign) stop working in
>>KDE (but not in text mode console)

I agree that c-acute exists in some languages : if you take a look at the
symbols in us_intl, the correct way to do a c-cedilla is to use altgr , + c

But as i3cc (sorry there's no name in your post dude) said, the keys accessed
with alt_gr aren't working on RH9 (they were working fine on RH7.3) at least
when you use the us_intl keymap (because when I use let's say an fr keymap
things work fine). So there is no way to produce a c-cedilla. Moreover, if
without switching to LANG=en_US, I didn't find a way to produce a " symbol in a
konsole : " + space produces some other kind of " incompatible with almost anything.

I hope this add-on will reopen the case since some of us really need the
international symbols with a US keyboard.

Emmanuel

Hello, guys.

In fact, THERE IS a way to produce a cedilla in us_intl. It's Multi_key + , + c
(one key at once). The problem is that, in Red Hat 8.0 and 9 (I don't know if it
is a Red Hat or XFree86.org problem), the Multi_key is not mapped in the 'us'
key symbol table. 

I fixed the problem by changing /usr/X11R6/lib/X11/xkb/symbols/us. I mapped the
Right Alt key to Multi_key. There is a copy of this modified version at
http://www.gs2.com.br/keyboard/ .

Also, there was a problem with Red Hat 8/9 version of Mozilla: when I pressed "
+ space, it printed ¨ instead of ". The problem was solved by upgrading Mozilla
to 1.4 (from RawHide).

Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:

        http://fedora.redhat.com/download

If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "CURRENTRELEASE".