[openi18n-im:01126] Re: iiimcf/iiimgcf/compose keys
Hideki Hiura <[email protected]>
| Newsgroups | gmane.comp.internationalization.input-methods |
|---|---|
| Message-ID | <[email protected]> |
Hi Owen, > From: Owen Taylor <[email protected]> > I don't have the full background here, but I think the concern was when > the selected language engine was something other than UNIT ... a > Chinese, or Japanese language engine, say. > > Are (latin) dead keys and compose key handling expected to work when > conversion for such a language engine is off? Thanks for the good question! This is a good oppotunity to explore my thought behind composition and language engine on/off issue! Let me start with my short recommendation, which is no, and open the discussion on the implication behind this. There are several aspects we can look at, especially with the history of input method and the notion of language engine on/off. Pre-input method days, the compose key and dead key handling was done in keyboard driver or in its sort, in several layer. Due to the input method introduced quite late in the game, as mostly addition additional single language support to what's inputtable by keyboard(driver) can generates, the notion of language engine on/off is also invented. But I doubt that idea is applicable universally now, especially after given multilingual input method paradigm. I would say it was just a histrical tactical necessity which we can fix by now. A right paradigm which we can introduce now is 1. to get rid of partial key operations the keyboard drivers or any pre-input method processings perform, and 2. to let Input method handles all input event always, and 3. to let a user to choose input language (and language engines for the language) instead of language engine on/off. So that the so-called-"language engine off"-state without composition is handled by English input method, and so-called-"language engine off"-state with composition is handled by, say French input method, German input method etc. Having said that, there is certainly the possibility that it is still too early for the paradigm shift :-), we can certainly retain the previous model for now and have a special code in libiiimcf for practicality reasons, seeking the best timing to purge later :-). Thanks! Hideki