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
