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

Marcel Schneider charupdate at orange.fr
Sat Nov 5 11:51:21 CDT 2016

Sorry not to have found time sooner to look close at the stuff 
that is claimed to support code unit sequences through dead keys.
Itʼs all about live keys, none about dead keys. 
Yet another case of talking past each other.

IMHO that happened because one simple question was not answered prior to 
sharing links to sources: How will the API know what line of aLigature 
(the ligature table) to look up, if the 0xf002 alias WCH_LGTR is not found 
in aVkToWch<n> (the allocation table)?

Indeed, column 1 of the ligature table contains the virtual key, and 
column 2 contains the modification number, that refers to the column of 
the allocation table where each 0xf002 or WCH_LGTR is mapped to a key and 
shift state:

// Modification_# >>>|0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|27|28|29|30|31|32|33|34|35|36|37|

static ALLOC_SECTION_LDATA LIGATURE16 aLigature[] = {
// |Virtual_Key|SC|ISO_#|Modif#|Char0|Char1|Char2|Char3|Char4|Char5|Char6|Char7|Char8|Char9|Char10|Char11|Char12|Char13|Char14|Char15|
{'Q'/*T1E C01*/,5,' ',0x2191,'q','_','n',0x2019,'e','x','i','s','t','e','_','p','a','s'}, // ^q doesn't exist

This leads again to the (off-topic) concern about some examples found on 
the internet. I’ll try to do some search for web pages in English, while 
we are looking forward to the advice that Doug Ewell kindly requested.


On Fri, 4 Nov 2016 23:22:42 +0100, Philippe Verdy wrote:

> Look at this example using LIGATURE3 (kbdinasa.dll : "ASSAMESE - INSCRIPT"):
> https://doxygen.reactos.org/da/dc5/kbdinasa_8c_source.html
> 2016-11-04 23:16 GMT+01:00 Philippe Verdy :
>> 2016-11-04 21:52 GMT+01:00 Doug Ewell :
>>> 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;
>> 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.

More information about the Unicode mailing list