Bug 149105 - iiimf-le-unit Latin problem with Multi_key
iiimf-le-unit Latin problem with Multi_key
Product: Fedora
Classification: Fedora
Component: iiimf (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
: i18n
Depends On:
  Show dependency treegraph
Reported: 2005-02-18 14:16 EST by David Monniaux
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-30 09:49:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
script for launching gedit (and only gedit) with Japanese input (155 bytes, application/octet-stream)
2005-02-19 08:51 EST, David Monniaux
no flags Details

  None (edit)
Description David Monniaux 2005-02-18 14:16:22 EST
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.
Comment 1 Jens Petersen 2005-02-18 21:54:48 EST
This looks similar to bug 130851.
Could you please look at that first and see if this is not the same problem?
Comment 2 Jens Petersen 2005-02-18 21:57:21 EST
Also which package version are you using?
Comment 3 David Monniaux 2005-02-19 08:42:19 EST
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?)
Comment 4 David Monniaux 2005-02-19 08:51:44 EST
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).
Comment 5 Jens Petersen 2005-02-21 04:08:35 EST
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?

Comment 6 David Monniaux 2005-02-21 11:30:18 EST
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.
Comment 7 David Monniaux 2005-03-17 16:54:31 EST
No progress?
Comment 9 Akira TAGOH 2005-09-26 22:47:49 EDT
Does this problem still happen in the latest im-sdk package for FC-3, 12.1-10.FC3.1?
Comment 10 John Thacker 2006-04-30 09:49:40 EDT
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.

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