2015-04-12 5:06 GMT+02:00 Andrew Cunningham <lang.supp...@gmail.com>: > > 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 level). 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).
