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:
static ALLOC_SECTION_LDATA VK_TO_WCHARS38 aVkToWch38[] = {
// 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|
{'Q'/*T1E
C01*/,0x01,'q','Q','#',0x2126,0x00f7,LGTR,0x0331,NONE,NONE,NONE,NONE,NONE,0x0634,'\\',0x0447,0x0427,0x0447,0x0427,'&','%',0x03c2,0x2211,'&'
,'%',0x05e7,'*','&','%',LGTR,LGTR,LGTR,LGTR,LGTR,LGTR,LGTR,LGTR,NONE,NONE}, //
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
};
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
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
};
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.
Marcel
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;
>>> } 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.
Received on Sat Nov 05 2016 - 11:51:53 CDT
This archive was generated by hypermail 2.2.0 : Sat Nov 05 2016 - 11:51:54 CDT