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

Doug Ewell doug at ewellic.org
Fri Nov 4 15:52:52 CDT 2016


Philippe Verdy wrote:

> Consider this source code (based on Microsfot "kbd.h", even if it is
> ported to ReadOS)
>
> https://doxygen.reactos.org/d7/df4/kbd_8h_source.html
>
> Look for the structures named with "LIGATURE"
>
> And now look at the special entry value "WCH_LGTR"=0xF002 (i.e. a
> PUA), which indicate these keys are mapped using those "LIGATUREn"
> structures (which have arbitrary lengths in WCHAR/UTF-16 code units),
> instead of storing a 16-bit code unit directly.
>
> <kbd.h> predefines LIGATURE1 to LIGATURE5 but longer lengths are
> possible (see cbLgEntry and nLgMaxd members in the KBDTABLE structure)
>
> The table of ligatures in linked from the pLigature member of the
> KBDTABLES structure, which points to the first set of LIGATURE1
> mappings.

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). But no such proof ever materialized.
There is still no documentation and no examples of any native Windows
keyboard that generates more than 4 code units from one keystroke.

kbd.h could declare:

	TYPEDEF_LIGATURE(8192)

and a user could compile it, and that would have nothing to do with
whether the Windows runtime could actually handle a LIGATURE structure
of that size.

Going beyond 4 seems like such a useful and intriguing enhancement, for
some folks anyway, that if it were possible, it should be easy to find
at least one example where some DDK developer has utilized it.

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;

Notice the absence of any array of 4, 6, or 8192 WCHARs. Only one WCHAR
can be composed from a dead-key sequence. This is why Mats was unable to
create a keyboard for double-accented letters that don't map to a single
BMP code point using dead keys. (Correct, Mats?)

A clarification: When I said "send or post the *actual code*", I assumed
you were creating KLC files and running them through kbdutool (bypassing
MSKLC), as you implied yesterday, not examining C++ code from the DDK. I
apologize for this unstated assumption and the confusion it caused, but
I still don't see any facts to support either the claim that a single
keystroke can generate more than 4 code units, or the claim that a dead
key combination can generate more than 1.

I'm currently trying to see if there is a Microsoft employee or business
unit that can resolve these questions for us once and for all.
 
--
Doug Ewell | Thornton, CO, US | ewellic.org



More information about the Unicode mailing list