From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Sat Sep 24 2005 - 08:10:14 CDT
From: "Anto'nio Martins-Tuva'lkin" <antonio@tuvalkin.web.pt>
>> The extended behavior could work by different criteria,
> <...>
>> - [acute][?] always produces [?][combining acute accent], which might
>> then be replaced by a precomposed character by NFC rules
> <...>
>
> Jukka, I like your ideas! :-) I more or less did this with Keyman (version
> 6.0), bit it still has some problems with AltGr, cursor keys, NumPad, etc.
That's the spirit of my keyboard too. Except that I combine the too
operations into one to produce directly the NFC form. As they are finite
with the existing finite number of base letters (due to Unicode stability),
the keyboard is complete forever, and can generate NFC directly for any
combination of a dead key and any letter which can be netered or composed on
the keyboard.
One strange thing in Microsoft drivers is the behavior of [dead key]
followed by [backspace]: the backspace is sent to the application, but the
character associated to the deadkey remains in the current state, and will
affect the character entered after Backspace. This looks like a bug:
[backspace] should cancel any waiting dead key state.
Same thing for other keys that are not not bound to a printable character,
but bound to functions or controls (arrows, PgUp, PgDown, Home, End, Enter,
Return, Del, Insert, Esc, F1..F12, Syst, PrintScreen, Pause) (in Windows,
they are syskeys, and not translated to WM_CHAR).
But keys that are bound to keyboard input state (no output in terms of
syskeys, such as Shift, Ctrl, Alt, AltGr, Capslock, Numlock, and even
ScrollLock or other state-shift keys like Roma/Kana and Hira/Kata keys on
Japanese keyboards, or mouse buttons and mouse moves on a tablet) should not
cancel this waiting dead key of course, unless these functions are
programmed to generate a character.
This archive was generated by hypermail 2.1.5 : Sat Sep 24 2005 - 08:12:31 CDT