Description of problem: iiimf-le-unit does not work correctly. Version-Release number of selected component (if applicable): 12.1 How reproducible: always Steps to Reproduce: 1. run in fr_FR.UTF-8 locale 2. yum install iiimf-le-unit 3. ln -s /etc/X11/xinit/xinput.d/iiimf as explained in Fedora documentation to get IIIMF in all locales 3. use gimlet to active the Latin unitle input method 4. use a keyboard with the Compose/Multi_key keysym mapped in (e.g. a Windows keyboard); if necessary, use xmodmap to map it 5. go in any application such as gnome-terminal, hit Multi_key ' e Actual results: some unprintable character appears Expected results: it should show é (e acute accent) Additional info: If one disactivates iiimf (by removing the symlink), one gets the correct behavior (using normal Xlib locale Compose maps). However, this prevents the user from changing on the fly to Japanese etc. input methods.
This looks similar to bug 130851. Could you please look at that first and see if this is not the same problem? Thanks
Also which package version are you using?
It is a related, but not identical, bug. By default, XMODIFIERS=@im=xxx will STOP any usual handling of dead keys by Xlib (which I have always found to be an extremely annoying "feature"). The solution offered within the iiimf framework, and suggested in bug 130851 #18, is to use iiimf-le-unit. However, as Beppe Castagna pointed out in #20, this does not work at all. So there are two bugs: 1) activating IIIMF results in normal dead key/Compose handling to be suppressed (maybe a "feature") 2) iiimf-le-unit does not work Version: 12.1 Release: 10.FC3 Build date: January 5, 2005 (Why isn't there a bugzilla entry for iiimf-le-unit?)
Created attachment 111226 [details] script for launching gedit (and only gedit) with Japanese input This script can be used to launch a gedit (or any other program) with the Japanese input method, without having to set us the whole desktop for Japanese (and thus avoiding the global effect of removing Compose / dead keys).
Well deadkeys work with some other IMs, so I'm not sure how XMODIFIERS in itself would stop deadkeys from working. (BTW in bug 130851#22 Beppe agrees that AltGr does work when Latin LE is on...) Is Multi_key bound by default for any X keyboard layouts btw? Otherwise to save time could you please describe how you bind it?
Previously, Multi_key was by default bound to one of the right Windows keys (but the machine I have FC3 on is a laptop with a nonstandard layout, so I have to bind it to a specific key). You can try putting the following into .Xmodmap: keycode 116=Multi_key and doing xmodmap .Xmodmap. Use xev if necessary to get a reasonable keycode. The AltGr mechanism doesn't have anything to do with Multi_key. In standard X localization, Multi_key is handled by Xlib, while AltGr is just part of the usual translation from keycodes to keysyms (keyboard map). The mechanism for dead keys and Multi_key is the same and is handled by files in /usr/X11R6/lib/X11/locale/XXX/Compose. (By the way, you may have a look at the header in /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose :-) ). I have never seen *any* XIM allowing the use of the usual dead key / compose mechanism, which is something that annoyed me for years. Certainly, neither kinput2, neither the iiimf "default" latin IM, neither the iiimf Japanese input methods allow it.
No progress?
http://openi18n.org/cgi-bin/bugzilla/show_bug.cgi?id=118
Does this problem still happen in the latest im-sdk package for FC-3, 12.1-10.FC3.1?
No response from reporter to request for info. Also, FC3 is the responsibility of Fedora Legacy. If the reporter can offer the needed information and this still occurs in FC4, please reopen. Note that iiimf has been replaced by scim for FC5, so it is unlikely that this will be fixed for FC4 if it is not already.