Mailinglist Archive: opensuse-m17n (59 mails)

[Mike FABIAN <mfabian@xxxxxxx>]

ghugh Song <ghugh@xxxxxxxxxxxxxxx> さんは書きました:

> One evidence is that every SuSE distribution has had the file 
> /usr/X11R6/lib/X11/locale/ko/Compose.
>
> It should be removed.  Otherwise ami (the Korean language
> input method ) gives no effect.

If the /usr/X11R6/lib/X11/locale/ko/Compose exists, you have to set
the environment variable XMODIFIERS correctly for Ami:

    export XMODIFIERS="@im=Ami"

If the ko/Compose file exists *and* a Korean XIM server like Ami is
running, it looks like as if therer are at two input methods available
for this locale, Compose and Ami (Compose is sort of a XIM server
built into the X-server). Then you have to indicate which one should
be used by setting XMODIFIERS correctly:

    export XMODIFIERS="@im=Ami"

to use Ami and

    export XMODIFIERS="@im=local"

to use Compose.

Usually XMODIFIERS="@im=Ami" is set automatically by ~/.xim when the
X-session is started in Korean, therefore this problem doesn't occur
if the home directory of the user was created during the installation
(default user) or later with YaST2, because then you have the
dot-files from /etc/skel copied to the users home directory, and among
these dot-files is ~/.xim and a ~/.xinitrc which sources ~/.xim.
Therefore it works for the majority of users out of the box.

It looks like you don't have/don't use ~/.xim for whatever reasons
and use some other scripts instead to start Ami. 
I recommend that you add

    export XMODIFIERS="@im=Ami"

to these scripts.

If the ko/Compose file doesn't exist and Ami is *the only* XIM server
running, then Ami is selected in Korean locale even if XMODIFIERS
is unset.

But this works only if no other XIM server besides Ami is running.  If
you have several XIM servers running at the same time, for example
kinput2 for Japanese *and* Ami for Korean, you have to set XMODIFIERS
correctly to indicate which one should be used, even if there are no
Compose files neither in /usr/X11R6/lib/X11/locale/ko/Compose nor in
/usr/X11R6/lib/X11/locale/ja/Compose.

> Yet, on every version of SuSE, I had to hand-remove this file.
> Even funny is that inside this file, there is a warning message 
> against tampering.

Yes, the following comment from the {ja,ko}/Compose files appears to
be nonsense:

    # This file currently has no entries.  It appears that a compose file (even
    # just an empty one) is required for the appropriate keysyms to work for
    # this encoding.

it is not true that an empty Compose file is necessary, you can delete
it and it still works. You even have the benefit that one XIM server
works for that locale without setting XMODIFIERS. I.e. that comment
really appears to be bogus.

Nevertheless I think it is a good idea to always set XMODIFIERS
correctly. If you rely on Ami working with XMODIFIERS unset because
the Compose file is deleted, you will probably be very confused when
Ami suddenly stops working as soon as a second XIM server is started.

If XMODIFIERS is set, the existance of the Compose file doesn't hurt.
That's why I didn't delete it, because I assumed that XMODIFIERS is
always set correctly.

I'll probably delete the {ja,ko}/Compose files for SuSE 8.2 though
because such an empty compose file really makes no sense.  And even a
non-empty Compose file is probably useless for ja_JP.eucJP and
ko_KR.eucKR locales, because most of the characters which you
typically can input via the compose mechanism are not possible to
display in EUC-KR or EUC-JP encoding anyway.

I'm not yet sure about the Compose files in

    /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose
    /usr/X11R6/lib/X11/locale/ko_KR.UTF-8/Compose
    /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/Compose

(The directories ko_KR.UTF-8 and ja_JP.UTF-8 are new in XFree86 4.3.0,
previously the contents of the en_US.UTF-8 directory were used for
ko_KR.UTF-8 and ja_JP.UTF-8 as well).

In CJK UTF-8 locales, using Compose may make sense, but I don't yet
understand it fully. I found that it is possible to switch between
using Compose, Ami, and kinput2 when using mlterm >= 2.6.3 in
en_US.UTF-8 locale like this:

    XMODIFIERS=@im=local LC_ALL=en_US.UTF-8 mlterm &

now Compose can be used to input special European characters, for
example German. Then one can open the mlterm config menu by pressing
"Control + right-mouse" and switch to Korean input using Ami or
Japanese input using kinput2 and also switch back to the "local" input
method to use Compose again.

What I don't yet understand is why this only works when mlterm
is started in en_US.UTF-8 locale with XMODIDIERS=@im=local.
When starting mlterm like this:

    XMODIFIERS=@im=local LC_ALL=ja_JP.UTF-8 mlterm &

Compose doesn't work, but switching to Korean input using Ami
or Japanese input using kinput2 is possible with the mlterm config
menu. And if mlterm is started in en_US.UTF-8 locale like this:

    XMODIFIERS=@im=kinput2 LC_ALL=en_US.UTF-8 mlterm &

Japanese input using kinput2 doesn't work and switching to compose
using the config menu of mlterm doesn't work either, although
switching to Korean input using Ami works.

This behaviour is strange and I don't really understand it, therefore
I don't know what to do with the Compose files in the UTF-8
directories:

    /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose
    /usr/X11R6/lib/X11/locale/ko_KR.UTF-8/Compose
    /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/Compose

Currently, they are all identical to the one in the en_US.UTF-8
directory.

-- 
Mike Fabian   <mfabian@xxxxxxx>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。