Oh well I thought it was a limitation of MSKLC, now your link shows that
this is a limitaiton of the keyboard drivers DDK for Windows itself.
Deadkeys should be perceived not really as keys but as functions allowing
to select temporarily another keymap.
These keymaps should just be indexed (16-bit is enough for this index, it
does not absolutely require to be indexed by a valid code point). Now each
key in this keymap should be allowed to produce not just one WCHAR (not
enough for a full character outside the BMP), but possibly more.
One solution: the mapped target WCHAR could reuse the surrogate values
(which should not be used as a legit output) to contain a "string ID", and
there would then be a table of strings indexed by this (surrogate value)
string ID. These mapped strings would no longer be limited in length, and
could even contain multiple UCS characters (preferably in NFC form).
If using surrogates is not the best option for these indexes, the structure
contains also a 16-bit flags field. These flags would indicate that the
target WCHAR is not a true character to output, but may indicate that:
- 1st flag: the target WCHAR is not a character but is a keymap ID (built
for the same deadkey state). Normally, each keymap is a table containing
for each source virtual key what to generate in output, each entry
contaning the flags and the WCHAR as before, allowing chaining (each table
should contain an entry to map the Spacebar virtual key, each entry
requiring just 32-bits, plus the external storage of the strings table).
- 2nd flag; the target WCHAR is not a character but is a string ID
(containing the actual output string with 0 or more WCHAR inside); the
string ID could be an offset addresss within the actual string table, each
entry starts with a WCHAR containing the number of WCHAR that follow and
that will be ouput from the keyboard.
- other flags coudl be still used to generate not characters but some
"system" virtual keys (e.g. multimedia function keys, or user programmable
keys, configurable separately and using user's preferences).
These tables could still be specific to the internal MSKLC driver
generated. MSKLC would generate and index the string table itself, avoiding
duplicate strings (which could our due to multiple ways to compose the same
output string). MSKLC should also take care of storing these strings in NFC
form. The existing standard keymaps will not use these string tables
because their output is only one WCHAR per composition sequence.
The actual generated driver will still process and return keyboard events
(virtual keys, or characters, depending on the level of event translations)
from these internal tables but should not have to deal with the expected
output encoding. The Windows internal DDK would make itself the
translations from UTF-16 NFC strings (or isolated WCHAR) to other encodings
(for example in the current Console's input codepage), which may be a lossy
conversion or could signal the user with a "beep" is the conversion fails
in the target encoding.
2013/7/31 Richard Wordingham <richard.wordingham_at_ntlworld.com>
> On Wed, 31 Jul 2013 22:49:07 +0200
> Philippe Verdy <verdy_p_at_wanadoo.fr> wrote:
>
> > However, the MSKLC does not allow the target of a (dead-key + another
> > key) to produce another dead key, it can only produce an ouput string
> > (containing at most four 16-bit code units). So dead keys cannot be
> > chained.
>
> Michael Kaplan gives a very plausible counterargument at
> http://blogs.msdn.com/b/michkap/archive/2004/12/17/323257.aspx . It
> was also my disappointing experience that MSKLC (an old version,
> admittedly) would not allow dead-key plus other-key to yield a
> 'ligature', i.e. a sequence of code units. I discovered the problem
> when I wanted a dead key as an alternative to AltGr - I was finding
> AltGr a bit uncomfortable to use, but re-engraving the keyboard was not
> an option.
>
> Richard.
>
>
Received on Wed Jul 31 2013 - 21:48:48 CDT
This archive was generated by hypermail 2.2.0 : Wed Jul 31 2013 - 21:48:51 CDT