星期日 2005年03月27日

A very good website about Traditional Chinese I18N/L10N processing Just read one very good website about Traditional Chinese I18N/L10N processing, see: http://wiki.debian.org.tw/index.php/ChineseInformationProcessing I got it from Jserv's blog: http://blog.linux.org.tw/~jserv/archives/001084.html Thanks jserv and some other people's hard work to collect so many good Chinese processing informaiton. ( 2005年03月27日, 11:49:41 下午 CST ) Permalink 评论 [0]

Reply James Su 答苏哲书: Reply for James Su's comments: http://blogs.sun.com/roller/comments/eyan/Weblog/what_s_difference_between_iiimf#comments In your comments, too many subjective, unproven statements would just create confusion and not beneficial, so I would stay just correcting the misunderstandings. It is wasteful to split precious resource into two projects especially if as James says SCIM can support thin client to rich client as IIIMF do. SCIM does not have a scalability of distributed framework and IIIMF does not have simplicity of library. It's just the design difference. You do not have to attack by using emotional groundless arguments like James> In my view, IIIMF is more like a commercial/close source James> product. It's not a good opensource project. It would be ideal to work together instead of splitting the resources. We all better understand that every medal has two sides. Then you can see so many minunderstandings you have: * James> 1. IIIMF must use namespace storage api, It makes almost impossible to use 3rd input method library in IIIMF LEs, because those libraries always handle files/databases themselves. -> SCIM does not provide namespace, LE has to handle by themselves. * James> 2. IIIMF must handle multi-user issue It makes LEs much complex than single user model.I always don't understand why input method should be a system wide service. Why input method can't be an user application just like firefox OOo or something else. -> Acturally not correct, IIIMF can also use vmseperator for single user model. -> SCIM is not capable of multi_user, so serious LEs who WANT to handle multi_user won't work. * James> 3. Must implement aux object to get better GUI Implementing. aux object is nightmare for input method developers, at least for me. -> Actually not correct. -> SCIM is not capable of per AUX/LE, so serious LEs who WANT to handle AUX won't fit well. * James> 4. Very few utility functions to help development LEIF is just an API interface, it lacks a library which contains utility functions to help LE developement. -> very subjective * James> 5. LEIF interface is very hard to use Just as jserv said before, he spent several weeks(days?) to hack iiimf-chewing but couldn't get it work. But only spent half of a day to get scim-chewing work. -> LEIF interface provides multiple levels for flexibility. Should choose right level of interface. There is also one chewing module in IIIM tch_le_sun LE, totally ONLY 600 lines of source codes, but support all the features of chewing, including customizable preedit/candidate windows, user perference for chewing input method properties(developers need only specify the properties arguments and need NOT write any GTK/QT sources to implement it), warning beep for wrong input sequence, keyboard layout displaying for 8 kinds of different keymappings, support hundreds of users with different preferences at the same time in ONE single backend thread, etc. While SCIM chewing module spend 1200 lines, and still some of the above features are not supported in SCIM chewing module. -> SCIM LE interface is not flexible to keep ABI due to C++. * James> 6. Many design/implementation issues for example: James> a) Doesn't support multiple input methods in one LE very well. -> Not true. James> b) Doesn't support Key Release event (has it been fixed?) -> This is true for the moment. Will be fixed. James> c) xaux is tightly binded to X Window -> This is true, as SCIM's helper is also tightly binded to X Window. -> Don't forget AUX is originally designed for Java object. * James> Otherwise there wouldn't be so many additional wrapers on top of James> IIIMF, eg. Unihan, ThizInput etc. -> They are not wrappers. Anyway, both IIIMF and SCIM have their advantages, and disavantages, if we put precious resources together on input methods improvement, I think, the community and end users will applause for the cooperation of IIIMF and SCIM. ( 2005年03月27日, 08:55:56 下午 CST ) Permalink 评论 [2]