> * Finally, 'Space' turns off the precomposition area and the composed
> CJK char is made available. Hitting Space results in TWO XEvents
> being passed to LyX. The first one corresponds to the creation of the
> CJK char and the second to the Space. CG wants to print the CJK char
> and 'swallow' the Space.
'Space'??? Hardcoding a key binding of a certain IM server is wrong.
In general, Japanese IM servers allow users to configure key bindings.
But it is a common practice here to bind 'Space' to the request for
a conversion candidate, so the fixation of a conversion is bound to
some other keys, most typically the 'Return' key.
Hence this one:
> if (kbuflen > 1) {
> for (i = 0; i < kbuflen; ++i) {
> draw_char(keybuf[i], ...);
> }
> } else if (isRegular(key)) {
> ...
is the only guaranteed way of processing CJK inputs, while this one:
> // Or whatever test you now use to indicate that
> // precomposition is finished
> if (key == XKSpace and stored_kbuflen > 1) {
> int i;
> for (i = 0; i < stored_kbuflen; ++i) {
> draw_char(stored_keybuf[i], ...);
> }
is almost sure to fail for Japanese inputs.
Japanese as well as Korean use transliteration scheme for inputting
methods while Chinese people use something completely different.
On the other hand, Chinese and Japanese share the tradition of
writing without any visual mark for word delimiters, while Korean
seems to have a peculiar and wired habit of inserting spaces(!!!)
between words.
OK, here is a typical Japanese input session sample:
- Type Shift+Space to activate an IM server.
- Type my name "miyatashigeru".
Now the IM server compose the input on the fly and shows
hiragana characters 'mi', 'ya', 'ta', 'shi', 'ge', and 'ru'
on the screen. Thanks to CG's effort, these characters
should appear at the client(LyX)'s cursor position.
Especially, the client's cursor is covered hidden from
user's view by characters and the cursor drawn by the
IM server.
- Type 'Space' to request a conversion candidate.
The IM server communicate with a language engine.
The language engine guessing word boundaries in the input
and returns the first conversion candidate for each word.
The IM server, then, shows the converted kanji character
string instead of the previously shown hiragana string.
The IM server's cursor is located at the last position of
the input and the word "shigeru" which contains the cursor
position is highlighted.
- You can move around the IM server's cursor to highlight whichever
word in your input.
-- If you don't like the word division the language engine has
guessed, you can extend/shrink the right boundary of the
selected (highlighted) word with some key combinations.
Then the IM server communicates again with the language
server and let it retry to guess the word boundaries in
the subsequent string and retrieves the conversion
candidates of these affected words and shows the result.
-- If you don't like one of the kanji conversion candidates the
language engine returns, you can select the word and request
another candidate by typing 'Space'. For example, the most
commonly used kanji character for the name "shigeru" is U+8302
(see http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=8302
)
so it is probable that the language engine choose this kanji
character as the first conversion candidate. However, the
correct kanji for my name is U+7E41.
(see http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=7E41
)
So I may have to select the word "shigeru" and type 'Space'
again to obtain this one.
The language engine will remember users' preference after
a few fixations.
It is also common here to configure an IM server so that
after a few tries of conversion requests one by one,
a type of the 'Space' key will requests all the possible
candidate conversions so that the IM server can show them
all in a separate window once for a user to choose from.
(Remember Angus' screen shot?)
Notice, so far, all the event handlings are performed by
the IM server, so they must be filtered out by the toolkit
(xforms).
- Now if you are satisfied with the kanji conversion, type 'Return'
to fixate your input.
The toolkit finally obtains a meaningful string from the
IM server to be passed down to the client. The client
displays the received string and move the cursor and notifies
the change of cursor position to the IM server so that it
can adjust the input location.
I guess it is a little bit more complicated than a typical Korean input.
Regards,
Shigeru Miyata
