Re: Combined Yorùbá characters with dot below and tonal diacritics

Philippe Verdy verdy_p at
Sun Apr 12 00:07:01 CDT 2015

2015-04-12 5:06 GMT+02:00 Andrew Cunningham < at>:
> Hi Ilya,
> The problem with approach documented below is two fold:
> 1) the characters required do not all exist as precomposed characters
thus microsoft's dead key sequences will not work for yoruba.

It's effectively a good catch that MSKLC (version 1.4) cannot produce
sequences of characters (just one code point) with dead key sequences or
anywhere it its keymap (independantly of the current keyboard state).

This is effectively a strong limitation. Dropping that limitation would
require updating the parsing format of the *.klc files to accept strings or
sequences of codepoints, and also update the internal code of its generated
driver so that it can map to a string (that the driver at run time will
send with multiple WM_CHAR events)

For now, all you can do is to generate a keymap that generates single code
points, and map additional keys for the combining characters needed.

May be Michael S. Kaplan (author of MSKLC at Microsoft) could review that
limitation and propose an upgrade so that MSKLC would really be compliant
with the Unicode character encoding policy without forcing users to enter
every code point separately and map them separately on their keymaps.

Also drivers generated by MSKLC 1.4 do not fully comply with Windows 8 and
Windows Server 2012: notably they have serious issues when used with a
touche interface (pressing AltGr + one character for example with the
onscreen maintains the Altgr state active if we don't type another
character WITHOUT the AltGr character; other keyboard states are also
mixed, including SHIFT, CAPSLOCK, where they do not match the state for the
physical keyboard).

The problem being that if you use the onscreen keyboard to locate a
character and then type with the physical keyboard, the physical keyboard
will continue to use that state (in my opinion it is a bug of Windows 8 and
Windows Server 2012, this bug does not exist in Windows 7 when we use the
its onscreen keyboard!) Windows 8 nad Windows server 2012 also have TWO
separate onscreen keyboards that do not work the same way.

Note also that drivers generated by MSKLC 1.4 lack some data need to map
correctly with an onscreen geometry (these drivers are only based on "VK_*"
virtual key numeric identifiers there's no data in the MSKL drivers to map
the virtual keys on a geometric layout, Windows 8 and Windows Server just
provide a default mapping of vkeys using some default geometries (but it
fact it cannot correctly infer the effective geometry to use, such as the
form and placement of the return key, and keys around it).

MSKLC does not provide a way to build another geometry and map geometric
keys to vkeys (or the revers).


Note also that (since always), MSKLC generated drivers have never allowed
us to change the mapping of scancodes (from hardware keyboards) to virtual
keys, aka "vkeys", or to "WM_SYSKEY" (this is hardwired in a lower internal

These drivers only map sequences of one or more "vkeys" (and a few
supported states, it's not possible to add keyboard states other than CTRL,
SHIFT, CAPSLOCK, ALTGR2, and custom states for dead keys) to only one
WM_CHAR. And it's not possible to change the mapping of vkeys to WM_SYSCHAR
(this is also hardwired at a lower level).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unicode mailing list