Another use case: being able to type Bopomofo along with Cyrillic or Kanas...; and new extensions will be needed for the 2012 German layout and other layouts made according to the ISO standard (you cannot do all what you want with just a few modifier bits and Windows only implementing a Kana modifier key and limiting the number of modifiers supported even below the capacity of the WORD ModificationNumber !
2016-11-06 5:37 GMT+01:00 Philippe Verdy <[email protected]>: > Note: such extension is absolutely necessary for scripts not encoded in > the BMP (e.g. Gothic or Deseret, or larger scripts that will absolutely > need mechanisms like dead keys if they want to have a usable keyboard > layout !) > > 2016-11-06 5:32 GMT+01:00 Philippe Verdy <[email protected]>: > >> >> >> 2016-11-06 4:11 GMT+01:00 Marcel Schneider <[email protected]>: >> >>> On Fri, 04 Nov 2016 15:30:48 -0700, Doug Ewell wrote: >>> >>> — And with LATIN CAPITAL LETTER OPEN E? Why not this way (as has been >>> suggested): >>> /*TILDE&AIGU */ DEADTRANS( 0x0190 ,0x1e4d ,{0x0190,0x0303,0x0301} ,DKF_0 >>> ), // *LATIN CAPITAL LETTER OPEN E WITH >>> TILDE AND ACUTE >>> >> >> This snippet cannot work as is, because the DEADTRANS() macro maps >> gernerates a 8-BYTE structure only has a single WCHAR for storing the >> result of the map of a (VKEY+modifier number): >> >> typedef struct _DEADKEY { >> DWORD dwBoth; >> WCHAR wchComposed; >> USHORT uFlags; >> } DEADKEY, *PDEADKEY; >> >> So it will need to map a WCH_LGTR instead, and then use a "ligature" >> table to store the string containing the 3 code units you want. >> >> Then there's an unused BYTE in the DEADTRANS structure for the flags, >> that can be used (specifically for entries mapped to WCH_LGTR) to pass >> flags to the LIGATURE(n) table (where there's also a free BYTE in the >> indexing key, allowing to pass an identifier needed for the lookup in the >> LIGATURE(n) table; alternatively, instead of mapping WCH_LGTR (a PUA), you >> could as well map another PUA there in 0xE001.0xE0FF for passing a byte for >> the deadkey state into the lookup of ligatures: >> >> #define TYPEDEF_LIGATURE(i) \ >> typedef struct _LIGATURE ## i { \ >> BYTE VirtualKey; \ >> WORD ModificationNumber; \ >> WCHAR wch[i]; \ >> } LIGATURE ## i, *PLIGATURE ## i; >> >> which can safely be changed to: >> >> typedef struct _LIGATURE ## i { \ >> BYTE VirtualKey, DeadKeyState; \ >> WORD ModificationNumber; \ >> WCHAR wch[i]; \ >> } LIGATURE ## i, *PLIGATURE ## i; >> >> (in the current definition of <kbd.h> the extra byte is implicit for the >> alignment, but not declared explicitly, it is implicitly filled with zeroes >> by C compilers when declaring the structure, but in my opinion this extra >> byte should have been declared explicitly.) >> >> But now it's up to the OS to support it, may be it works already if the >> lookup in the LIGATURE(n) table already scans for values of a DWORD, >> including this free padding byte, however there's a need to change some >> code in the kernel-level to check the PUA values mapped in DEADKEY >> structures and extract a DeadKeyState from it. >> >> The alternative is to map the combination of two deadkeys to a bit in the >> modifier number (this can be instructed by the uFlags, which will set the >> modifier bit number specified in the mapped PUA). In all cases there's >> still space for extension there. >> >> The last alternative is to extend the KBDTABLES structure to append new >> members for a table of extended DEADKEYS, and a separate table of LIGATURE >> for DEADKEYs (the KBDTABLE does not specify its own size, but it has a >> fLocaleFlags field just before the table of ligatures, which can indicate >> the presence of these extensions. >> > >
