From: "Philippe Verdy" <[EMAIL PROTECTED]> > As far as I know, an application has little control on the subset of > character it can accept from an IME, or keyboard driver, and if some > characters in the generated combining sequence are ignored, and some other > are accepted, it creates a new sequence which may not be appropriate in the > target subset.
Once again, you are not really speaking acurately to what the system is doing. Though at least you ar tempering your words a bit more than you used to (e.g. "as far as I know...") so that people do not think you are speaking definitive facts. In this case, a Unicode application can of course accept anything. A non-Unicode application is pretty much limited to characters within the default system code page. HOWEVER: Note that before one can switch to a particular keyboard layout on Windows, a WM_INPUTLANGCHANGEREQUEST message is recieved, asking for permission to change to a given language. The application can simply not accept the change, in which case it will not happen. I would humbly suggest that this gives the application a LOT of control over the subset of characters it will receive. HOWEVER REDUX: There is really no case where the behavior you suggest ("if some characters in the generated combining sequence are ignored, and some other are accepted, it creates a new sequence which may not be appropriate in the target subset") happens in CJK, and almost no case where it happens outside of CJK. What actually happens is the the Unicode character is converted to the default system code page, which will mostly produce question marks for all of the characters off of that code page. The one exception is cases of "best fit" mappings, but this is really not a CJK phenomenon. > So clearly this is not a Unicode issue, but an issue with the usability of > keyboards and IMEs with all applications that are assuming the complete > support of the keyboard subset in the text they accept (if you don't know > what I mean, just look at the remaining number of games that are just > interpreting keycodes or that are assuming a US keyboard layout, and that > are hard or impossible to use with their default keyboard control > assignments, as they are mapping for example Alt+digit keystrokes, when some > keyboards will not be able to generate these keystrokes without an > additional shift key modifier, and you'll get a good example about the > usability of a enhanced keyboard in a context where it was assumed that all > keyboard sequences were possible). Such behavior is an application limitation that is even beyond the limitations of non-Unicode apps. But thisr really has nothing to do with the original question -- which as actually for a UNICODE application. This strange CJK tangent is a thread best abandoned. MichKa [MS] NLS Collation/Locale/Keyboard Development Globalization Infrastructure and Font Technologies