From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; nl-NL; rv:1.2.1) Gecko/20030225 Description of problem: Hello, I'm using RedHat 9 in the Dutch language. I also use the Gnome Keyboard Switcher, to switch between keyboard definitions. You know, the "international" (deadkey) and the USA variant. When it is in deadkey mode I should be able to type double quotes by first hitting the quote key and then the spacebar. But: in Mozilla (webforms like the one where I am typing this bug) *and* in OpenOffice this creates not a double quote character, but just a space with umlaut/tréma/diaeresis, like this: ¨ instead of " So when writing long texts (where I prefer to use the deadkey mode) I have to switch between the two keyboard language settings all the time, when I need double quotes somewhere. In the American mode, I can type a quote character by just hitting the corresponding key, but there I can not (easily) type characters like éïô and the like... I need them because I write in four different languages sometimes. This switching all the time is very annoying. It distracts me from creating text. Evolution had the same problem, until I upgraded that application through the Ximian Red Carpet service. It's now 1.4.0 and I'm having no more problems with it. There is no problem in Gedit either, so I can't say for sure which applications are to blame and which not. I can test other programs, if so asked. I saw reference to a very comparable bug 64573. It is closed because it had to do with RedHat 7.3, not 9. It also speaks about KDE, which I don't use. But apart from that, it looks much the same. If needed I can of course provide files etc. as attachments - I just don't know at this point which ones to send. Forgive me, I' m just a user. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: see description Additional info:
hmm, so mozilla and openoffice are broken, but gtk 2 applications seem to work.
I can now confirm that the same problem exists in The Gimp, Dia and Xchat. So it's not just Mozilla and OpenOffice.
I can't reproduce the problem; dead_diaresis+space works fine for me in xterm and other apps that use the standard Xlib compose tables. you might want to check with 'xev' whether the key is producing the dead_diaresis key symbol. If it is, then it's going to be a XFree86 problem; if not, then it would be a problem with the gkb keyboard maps. (The thing is a menace, it should be deleted from the distribution; you may want to install http://gswitchit.sourceforge.net/, which is vastly better implmentation-wise.)
Hello Owen, you said that dead_diaresis+space works fine for you - meaning that it produces the desired double quote character? I have tried xev and this happens when I have my keyboard in deadkey mode, when I hit shift and the double quote on the keyboard: KeyPress event, serial 273, synthetic NO, window 0x3600001, root 0x48, subw 0x0, time 21371267, (-28,256), root:(845,827), state 0x10, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 273, synthetic NO, window 0x3600001, root 0x48, subw 0x0, time 21375230, (-28,256), root:(845,827), state 0x11, keycode 48 (keysym 0xfe57, dead_diaeresis), same_screen YES, XLookupString gives 2 bytes: "¨" KeyRelease event, serial 273, synthetic NO, window 0x3600001, root 0x48, subw 0x0, time 21375420, (-28,256), root:(845,827), state 0x11, keycode 48 (keysym 0xfe57, dead_diaeresis), same_screen YES, XLookupString gives 2 bytes: "¨" KeyRelease event, serial 273, synthetic NO, window 0x3600001, root 0x48, subw 0x0, time 21376452, (-28,256), root:(845,827), state 0x11, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: "" And in USA mode: KeyPress event, serial 126, synthetic NO, window 0x3600001, root 0x48, subw 0x0, time 21641784, (78,-11), root:(93,141), state 0x10, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 126, synthetic NO, window 0x3600001, root 0x48, subw 0x0, time 21642624, (78,-11), root:(93,141), state 0x11, keycode 48 (keysym 0x22, quotedbl), same_screen YES, XLookupString gives 1 bytes: """ KeyRelease event, serial 126, synthetic NO, window 0x3600001, root 0x48, subw 0x0, time 21642785, (78,-11), root:(93,141), state 0x11, keycode 48 (keysym 0x22, quotedbl), same_screen YES, XLookupString gives 1 bytes: """ KeyRelease event, serial 126, synthetic NO, window 0x3600001, root 0x48, subw 0x0, time 21644038, (78,-11), root:(93,141), state 0x11, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: "" You say it is now an XFree86 problem? It does not really matter to me, because like I said, I'm mostly a non-technical user - who just wants this thing fixed whatever the underlying trouble should be :) Isn't there anything that I can do about it, myself? Edit a little file or something?
Actually, I was wrong about it working for me - it was hard to tell the difference between " and ¨ in ther font I was using in an xterm. If you want to work around the problem on your system you can change, in: /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose <dead_diaeresis> <space> : "¨" diaeresis to: <dead_diaeresis> <space> : "\"" quotedbl I'm reassigning the bug to the XFree86 component; this has been fixed in upstream XFree86 (Mike - see change to cvs/xc/nls/Compose on 2003/04/03), so we can probably just pull that change into our package.
Great, thanks for the hint of editing the "Compose" file. """""""""" :) (and sorry for the double post of comments above, I was just browsing back and forth with Mozilla in the bug system, and somehow submitted the thing twice)
FWIW, this issue is reported many times in bugzilla already, both ours and upstream's. I believe the patch is in rawhide already, if not it's in my patch queue which I'll be processing when I return from vacation. If someone tests latest rawhide and reports back here, please close bug if it works right in rawhide. Thanks.
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: 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.