Bug 76248 - lang=en_US.UTF-8 gives bad us_intl keyboard output
lang=en_US.UTF-8 gives bad us_intl keyboard output
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-18 14:07 EDT by JLapham
Modified: 2007-04-18 12:47 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-20 11:01:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description JLapham 2002-10-18 14:07:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Description of problem:
If LANG=en_US.UTF-8

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Selecting "US English" from the gdm window before logging in.
2. Login.
3. Add the Keyboard Layout Switcher app to the gnome2 panel
4. Make one of the keyboards use command => "gkb_xmmap us_intl"
5. Switch to this keyboard.
6. Start the OpenOffice.org writer app.
7. Type 'c, should give g, but doesn't
8. Logout, change language in GDM to system default
9. Login.
10. Switch to the "us_intl" keyboard
11. Start OOo writer, type 'c (apostrophe c) which correctly gives g

	

Actual Results:  The  "c"-cedilla g is not be produced

Expected Results:  The  "c"-cedilla g should be produced

Additional info:

When gdm language is set to "US English" the env var LANG=en_US.UTF-8, when the
gdm lang is set to "System default", LANG=en_US.

Thus, I think this env var must have csomething to do with the problem.
Comment 1 JLapham 2002-10-19 02:39:34 EDT
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.
Comment 2 Havoc Pennington 2002-11-04 16:49:55 EST
I'm assuming this is a gkb_applet problem, but I'm not sure really.
Comment 3 Need Real Name 2002-11-14 16:23:53 EST
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.
Comment 4 Need Real Name 2002-12-18 03:00:36 EST
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)
Comment 5 JLapham 2002-12-18 05:24:43 EST
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
Comment 6 JLapham 2002-12-18 05:31:56 EST
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.
Comment 7 Havoc Pennington 2002-12-18 19:49:32 EST
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.
Comment 8 Need Real Name 2002-12-18 20:19:25 EST
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.
Comment 9 JLapham 2002-12-20 09:04:37 EST
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
Comment 10 Havoc Pennington 2002-12-20 09:58:03 EST
Adding CC to see if anyone has a clue.
Comment 11 Mike A. Harris 2002-12-20 10:18:41 EST
What happens if you open up a terminal, and set the keyboard to us_intl
manually via setxkbmap?
Comment 12 Owen Taylor 2002-12-20 10:32:44 EST
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"

Comment 13 JLapham 2002-12-20 10:56:46 EST
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...   :)
Comment 14 Havoc Pennington 2002-12-20 11:37:23 EST
In any case, looks like it's definitely not a gnome-applets issue.
Comment 15 Mike A. Harris 2002-12-21 05:10:03 EST
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@xfree86.org 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@xfree86.org.

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.
Comment 16 Emmanuel Druon 2003-05-08 14:57:39 EDT
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
Comment 17 Fabio Gomes 2003-07-06 01:37:38 EDT
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).


Comment 18 Mike A. Harris 2005-04-20 11:01:39 EDT
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".

Note You need to log in before you can comment on or make changes to this bug.