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

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:37:50 CDT