Hi, From: "Maiorana, Jason" <[EMAIL PROTECTED]> Subject: RE: supporting XIM Date: Mon, 24 Mar 2003 11:11:31 -0500
> >What points do you think are "useless" on XIM? I don't know > >why you think so, whether because you really understand XIM or > >because you don't know about needed complicity and features > >for CJK support. > > Well, I find most XIM methods to be unstable, and crash alot. > Plus, they are far too dependant upon locale. I dont see why > a XIM method should have such fragile dependancies upon the > locale. > > I like to operate under en_US.UTF-8, but I like to enter > Japanese and vietnamese sometimes. The vietnamese input > method implemented under GTK+ works fine, no matter which > locale im logged into. The XIM method for Japanese seems > only to work under ja_JP.eucjp. You can send mails to ask for an improvement to support UTF-8 locales. Canna: http://canna.sourceforge.jp/ FreeWnn: http://www.freewnn.org/ Anthy: http://anthy.sourceforge.jp/ SKK: http://openlab.ring.gr.jp/skk/ XCIN: http://xcin.linux.org.tw/ However, locale-dependence itself is not a bad thing. For example, XCIN supports both of traditional and simplified Chinese depending on locale. We can imagine about an improvement that the default mode would be determined by locale even when it would support run-time switching of traditional and simplified Chinese. > Also it crashes alot, probably due to Canna being somewhat > unstable under rh8. (Start Japanese input and type wildly > for a second, cannaserver will lock up.) There seem poorly-implemented XIM clients which cause locking up of XIM servers. They are bugs of either XIM clients or servers. Please contact developers of them. > I think it should be much more stateless, allowing the client > library to do the rouma/kana conversions, and simply > having the server anwer queries for possible Kanji, of course > all in UTF-8. The state of the clients interface should be > kept on the client side, imo I think support of UTF-8 locales is a good improvement. Rouma/kana conversion is not as simple as you think, because conversion table is configurable in modern conversion engines. In SKK, rouma/kana conversion and kanji conversion are strongly connected from users' view and I don't think such separation can be achieved. kana->kanji conversion is much more complex. It is never a simple thing like one-to-one or one-to-many conversion. Timing of rouma->kana conversion and kana->kanji conversion is also a target of improvement for input method developers, like SKK does. There are also input methods which don't use rouma nor kana like T-Code. It is not a good idea to impose a standardized communication in the middle of conversion. There are many input methods with various various ideas and user interfaces algorithms by input method developers. Input method protocols must be as extensible as possible to allow input method developers to realize their ideas. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
