From: "Michael (michka) Kaplan" <[EMAIL PROTECTED]> > From: "Philippe Verdy" <[EMAIL PROTECTED]> > > > May be that's something to suggest to Microsoft for inclusion in a future > > version of its wonderful MSKLB tool, > > You mean MSKLC? I hope the "B" in your exposition stands for "Bodacious" or > something....
Yes I use it, but the acronym was wrong, as the tool displays its full name. I have rebuilt it by thinking B=Builder, take this as my memory has failed here. > > which works great to create keyboard > > drivers for alphabet/abjad scripts that use dead keys and AltrGr (or > > Alt+Ctrl on US keyboards), > > Have you tried the Right "Alt" key on such a keyboard? It acts as an AltGr > based on the layout, whether it says AltGr or not. Check out the help > file.... Yes I know that. And in MSKLC, enabling the AltGr support also activates the Alt+Ctrl substitute for US keyboards that traditionally don't make distinctions with which Alt key is used (also because there exists some US keyboards with only one Alt key, the left one). > What are you talking about? Both the built in Hebrew keyboard and any > keyboard you create can handle all of this just fine, and DO. Dead keys > would be inappropriate, so its great that they do not use dead keys here -- > you type the base letter than if you need a vowel or a point you type that. Exactly, this is what I meant in my sentence. > > The <AltGr+x+Unicode hex code point> keystroke sequence could be added to > > the existing support of <AltrGr+0+ANSI decimal code> and <AltGr+OEM > decimal > > code> keystrokes... and featured in a update for all supported keyboard > > drivers for Windows. > > Nice when people who have not looked at the source can talk about what could > be added. :-) OK I don't have the source of this tool. However it creates and links a DLL with support functions that could also, when explicitly enabled by marking a checkbox (e.g.), add support for Unicode hex sequences, mapped to a leading prefix that may be customized in a particular keyboard (like the <AltGr+X> key which could be replaced by another <AltGr+Y> key if needed). > One has to be careful about how much system support is added for things like > this, as there are those who use keystrokes for their own purposes that can > interfere. Others have noticed that such features seem to fade in and out > from time to time as they are attempted. You're true, there exists keyboards where AltGr+X is already mapped to a character. Better not breaking them, as long as it is possible to use another keystroke as the leader for hex sequences. > You mean input method editors (IMEs)? Yes. That is a short name for IME (and I don't think it is ambiguous when I have explicitly spoken about IME's). > Yes, IMEs can be developed. also note that for Vietnamese there is a > built-in keyboard that works -- have you tried it to type Vietnamese text? Yes, I use it. That was just an example for a case where multiple diacritics on a base letter is not practical to build with MSKLC (as it requires to map a code point for the combination of the first dead key with the next key, and this combination is not remappable to another dead key table)... And I have also a few keyboards created with MSKLB (don't say I was rambling against it, as I already said it was a "great tool") so that I can type in additional characters for various languages in a extended keyboard layout that remains compatible with my French keyboard (and adds a few missing French letters like the oe and OE ligatures, or the French double quotation marks).
