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

[Philippe Verdy]

2016-11-04 21:52 GMT+01:00 Doug Ewell <doug at ewellic.org>:

> OK, I understand now. We are rehashing the discussion on this list from
> August 2015, in which Marcel claimed that the presence of these lines in
> kbd.h:
>
> #define TYPEDEF_LIGATURE(i) \
> typedef struct _LIGATURE ## i { \
>         BYTE VirtualKey; \
>         WORD ModificationNumber; \
>         WCHAR wch[i]; \
> } LIGATURE ## i, *PLIGATURE ## i;
>
>         TYPEDEF_LIGATURE(1)
>         TYPEDEF_LIGATURE(2)
>         TYPEDEF_LIGATURE(3)
>         TYPEDEF_LIGATURE(4)
>         TYPEDEF_LIGATURE(5)
>
> was proof that some version of Windows actually supported ligatures
> longer than 4 code units (WCHARs).


Why then the SDK predefines a structure with 5 code units ???


> But no such proof ever materialized.
>

You'll find examples in the ReactOS  sources (the link I gave) that
provides drivers for many more languages than the two example drivers
provided with the SDK.


> And once again, that is not what Mats was talking about. He was talking
> about dead-key combinations not being able to generate more than ONE
> code unit. And if you go back and look at kbd.h, you will see this:
>
> typedef struct _DEADKEY {
>         DWORD dwBoth;
>         WCHAR wchComposed;
>         USHORT uFlags;
> } DEADKEY, *PDEADKEY;
>
> typedef WCHAR *DEADKEY_LPWSTR;
>

Here again, the support of 4 code points in structures allows binding
"ligatures" in keymaps, even if their entries contain a single WCHAR, using
the special value for "ligatures" (which are looked up in a separate table.

>
> Notice the absence of any array of 4, 6, or 8192 WCHARs.


You don't need to ! you assign a value WCH_LGTR=0xF002 (the PUA code unit),
which triggers a lookup in the "LIGATUREn" tables.


> Only one WCHAR
> can be composed from a dead-key sequence.


Wrong, you assign a WCH_LGTR and then ligature tables are used, they are
not limited to just one code unit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20161104/c631984d/attachment.html>