Hi, At 02 May 2002 23:54:37 +1000, Roger So wrote:
> Note that the source from Li18nux will try to use its own encoding > conversion mechanisms on Linux, which is broken. You need to tell it to > use iconv instead. I didn't know that because I am not a user of IIIMF nor other Li18nux products. How it is broken? > Maybe I should attempt to package it for Debian again, now that woody is > almost out of the way. (I have the full IIIMF stuff working well on my > development machine.) I found that Debian has "iiimecf" package. Do you know what it is? > I don't think xkb is sufficient because (1) there's a large number of > different Chinese input methods out there, and (2) most of the input > methods require the user to choose from a list of candidates after > preedit. > > I _do_ think xkb is sufficient for Japanese though, if you limit > "Japanese" to only hiragana and katagana. ;) I believe that you are kidding to say about such a limitation. Japanese language has much less vowels and consonants than Korean, which results in much more homonyms than Korean. Thus, I think native Japanese speakers won't decide to abolish Kanji. (Please don't be kidding in international mailing list, because people who don't know about Japanese may think you are talking about serious story.) Even if we limit to input of hiragana/katakana, xkb may not be sufficient. For one-key-one-hiragana/katakana method, I think xkb can be used. However, more than half of Japanese computer users use Romaji-kana conversion, two-keys-one-hiragana/katakana method. The complexity of the algorithm is like two or three-key input method of Hangul, I think. Do you think such an algorithm can be implemented as xkb? If yes, I think Romaji-kana conversion (whose complexity is like Hangul input method) can be implemented as xkb. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
