Bug 75079 - canadian french keyboard layout only works fully with some apps
canadian french keyboard layout only works fully with some apps
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-04 01:44 EDT by Gray Kimbrough
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-11-25 19:59:18 EST
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 Gray Kimbrough 2002-10-04 01:44:38 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809

Description of problem:
I selected the cf (canadian french bilingual) keyboard layout in the installer.
 Many applications, however, do not correctly render all keystrokes, in
particular the apostrophe, which must be made by combining left alt with the i
key, twice, since it acts as a dead key when applied to other letters.

This problem is noticeably lacking in gnome-terminals and gedit, but present in
xchat and gaim.  xchat seems to have additional problems rendering many special
characters, while gaim and mozilla are merely (I think) unable to render
apostrophes.

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


How reproducible:
Always

Steps to Reproduce:
1. Buy a canadian bilingual keyboard.
2. Install redhat linux 8.0 on a computer to which this keyboard is attached.
3. Attempt to type apostrophes in xchat or gaim.
	

Actual Results:  No apostrophes!

Expected Results:  Apostrophes.

Additional info:

I added the keyboard switcher applet, and everything works fine using the US
layout.  Output with the cf layout was unchanged, of course.

relevant portion of XF86Config, stripped of comments:

Section "InputDevice"
""
        Identifier  "Keyboard0"
        Driver      "keyboard"
        Option      "XkbRules" "xfree86"
        Option      "XkbModel" "pc102"
        Option      "XkbLayout" "ca_enhanced"   #Option "XkbVariant"    ""
EndSection
Comment 1 Mike A. Harris 2002-11-01 01:33:58 EST
Please report bugs like this directly to the upstream maintainer
of the package.

Closing WONTFIX
Comment 2 Owen Taylor 2002-11-25 17:57:38 EST
Actually, note:

 gaim/xchat/Mozilla => GTK+-1.2 apps => Use Xlib input handling
 gedit/gnome-terminal => GTK+-2.0 apps => Use builtin input handling

So this is apparently a Xlib problem ... more particularly, a problem
with the compose sequences for your locale in 

 /usr/lib/X11/locale/

What locale are you running in - that is, what does 'echo $LANG' give
from a terminal?
Comment 3 Gray Kimbrough 2002-11-25 18:08:34 EST
[jgk3@tertiary jgk3]$ echo $LANG
en_US.UTF-8
Comment 4 Owen Taylor 2002-11-25 18:56:24 EST
Wow, that's a pretty insane keyboard layout ;-)

The 'i' key seems to be completely unmodified from the standard en
layout though, as opposed to many other keys. It looks to me
that it doesn't give anything with the 3rd-level-shift.

I'm not sure what you mean by 'apostrophe' here; there are various
acute like things you could be trying to get:

 a single vertical quotation mark (what would be used for an 
  apostrophe in ASCII text)
 a right single quotation mark (what would normally be used for
   an apostrophe in printing)
 a standalone acute accent (a line angled to the right)
 
Can you specify exactly what keys you want to press (identify them
by where they are in respect to the alphabetic keys on the keyboard
"the key to the left of the l" with what modifiers (AltGR and
3 level shift, if you understand what keys those are, otherwise where
tehy are on the keyboard) and what output you want to get on the screen.

Thanks.
Comment 5 Gray Kimbrough 2002-11-25 19:59:11 EST
I agree that it's rather insane, but quite nice to be able to type two
languages, and a wealth of symbols, as well...

Typing any non-standard characters seems to be a problem in xchat, where, e.g.
i--found to the left of the right shift key--outputs as two characters.  The
standalone accent acute mark, which would normally be a left quotation mark, I
believe, is generally produced by altGr-i, twice.  Doing this in mozilla or
xchat has no effect now, i.e. nothing is produced.  The standalone grave accent
works, produced by twice hitting the key which is two keys to the right of L.

On the plus side, I figured out how to make an apostrophe--that is, a vertical
quotation mark--which on this keyboard amounts to shift-comma.  So, the main
problem is dealing with nonstandard characters like i and 5, and the acute accent.
Comment 6 Owen Taylor 2002-11-25 20:46:39 EST
For those following along at home:

 The character to the left of right-shift is eacute unshifted
 AltGr + that key gives dead_acute.

(Basically, don't try to enter i18n characters into bugzilla,
 it will just mangle them; I've never seen any luck in this
 area :-)

There is indeed a difference bewteen dead_acute + dead_acute
in the iso-8859-1 and en_US.UTF-8 compose sequences... 
in the iso-8859-1 sequences, dead_acute + dead_acute gave
acute (pretty useless really) while for the en_US.UTF-8 compose
sequences it acts as a "dead doubleacute" (pretty useless unless
you need to type in some Hungarian.) In neither case did it
give a single vertical quotation mark. (')

Shift-comma is most likely the simplest way of getting '.

Also you can get it as dead_acute + space.

dead_grave + dead_grave is going to give you a standalone grave,
which is useful if you are doing shell or Perl programming, but not
otherwise.

I don't think thjere is actually a bug here. (Well, there is a bug
in that the GTK+ compose tables and the en_US.UTF_8 Xlib compose
tables don't agree on the interpretation of dead_acute + dead_acute,
but I'll save worrying about that until some Hungarian complains.)

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