Kaixo! On Thu, May 02, 2002 at 02:14:08AM -0400, Jungshik Shin wrote: > BTW, Xkb may work for Korean Hangul, too and we don't need > XIM if we use 'three-set keyboard' instead of 'two-set keyboard'
If it is indeed doable, it wouldn't be very practical due to the high amount of possible combinations (the Xkb based solution consist to populate the Compose file with the various possibilities, I suppose). But that's true that hangul-only typing doesn't require any user interactivity at all, an on-the-spot method that just analyzes the input and convert to preformed hangul syllabes on the fly is enoguh. Note that Vietnamese also has a similar need for such a kind of simple input method; but as the raw XIM protocol is too complex for a simple non interactive input method there is nobody yet that does trough the trouble of writing one (currently you can type vietnamese using dead keys for the accents and the usual Xkb mechanism as for other latin alphabet based languages, but that isn't the preferred typing method for Vientamese people). Now, if by "Xkb is enough to type Korean" you meant typing directly the single jamos without composing, yes, that's perfectly possbile; but the produced output won't be in the standardized precomposed form for the common korena syllabes, that could be a compatibility problem if you exchange files written that way. >> Or, any software-specific input methods (like Emacs or Yudit)? > > Yudit supports Indic, Thai, Arabic pretty well as far as I know. Well, until now it used ascii transliteration tables; which is a bit of a pain if you use a non-US keyboard on a regularly base as you can't type directly the characters available on your keyboard, that is counterintuitive and frustrating. However, I read in the web page of yudit that the latest version supports Xutf8LookupString, that's good news, as it would allow someone to easily type in indic, thai, arabic, etc. without having to do anything special at all, just usiong their standard keyboard layout, as in all other programs (the transliteration tables are good to have for the occasional input in other languages/scripts; but for the default everyday input in the user language they shouldn't be needed) -- Ki �a vos v�ye b�n, Pablo Saratxaga http://www.srtxg.easynet.be/ PGP Key available, key ID: 0x8F0E4975 -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
