Re: Possible to add new precomposed characters for local language in Togo?

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Sun, 6 Nov 2016 05:40:59 +0100

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 <verdy_p_at_wanadoo.fr>:

> 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 <verdy_p_at_wanadoo.fr>:
>
>>
>>
>> 2016-11-06 4:11 GMT+01:00 Marcel Schneider <charupdate_at_orange.fr>:
>>
>>> 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.
>>
>
>
Received on Sat Nov 05 2016 - 23:41:35 CDT

This archive was generated by hypermail 2.2.0 : Sat Nov 05 2016 - 23:41:35 CDT