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

[Marcel Schneider]

On Fri, 4 Nov 2016 00:53:57 +0100, Philippe Verdy wrote:

> > What Mats wants is to enter , ,  and 
> > have the keyboard generate . That is 
> > the sequence of 3 output code units that the Windows architecture -- not 
> > just MSKLC -- does not support. If you disagree, please provide an 
> > example. 
> 
> I had perfectly understood that ! And my response was in line for this need: 
> 
> Pseudo-code: 
> 
> Table[Initialstate] [,] = StateDeadKey1 
> Table[StateDeadKey1] [,] = StateDeadKey1And2 
> Table[StateDeadKey1And2] [,] = NFC( deadkey1; deadkey2>) 
> 
> Each table entry can contain either a special value for a table index 
> (representing the current state), or a sequence of UTF-16 code units (the 
> number of code units depends on the table format, whose header indicates 
> how many code units are stored, and how many modifiers are mapped or 
> masked), or a null entry for unmapped keys). The maximum number of UTF-16 
> code units depends on the OS version which supports more formats (I think 
> it is now up to 6 code units in past versions it was 4, but there's an 
> extra format where table entries are in fact positions in a string table, 
> where strings have variable lengths: the string table just follows the 
> tables of keymaps, there's actually no code at all in most keyboard drivers 
> that don't need a special UI. 
> 
[…]

Does this work on Windows? Being not a programmer, I mainly ape and edit 
existing code, so to test this I need the exact spelling of the header and 
one complete line of the DEADTRANS function. Would you please provide a link 
to a source file or to a How-to page?

BTW when reading your comment, I suspect there is a mix of several sections.

Michael Kaplan knew that what you are claiming does not work:
“Every sequence of chained dead keys must end up pointing to a single 
UTF-16 code point; no sequence can be created;”
http://archives.miloush.net/michkap/archive/2011/04/16/10154700.html
(Michaelʼs blog post about chained dead keys, again.)

Having said that, your announcement (if true) shortcuts an enormous battle 
and greatly improves Microsoftʼs relationship to Unicode support and i18n.
Iʼm getting puzzled that this feature is being hidden instead of promoted.
Finally however Iʼd be less surprised given these two precedents:

1) When based on MSKLCʼs GUI I was in the same position of ignoring Windows 
support for serial dead keys, I vainly posted demands on Microsoft fora…
http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_devices/how-to-implement-multiple-deadkey-strokes/4ff38c09-b58c-490a-
963e-3cc745dfb396
https://social.technet.microsoft.com/Forums/windows/en-US/e61dad3a-dbe5-4c5e-88af-7fc33cbb2e6a/multiple-deadkey-strokes-still-not-implemented-
on-windows?forum=w7itproappcompat
…until I found full explanations on the keyboarding page of MNAʼs website:
http://accentuez.mon.nom.free.fr/Clavier-CreationClavier.php

2) The issue about the maximum number of code units input by a single key press.

So we look forward to any supplemental information, hopefully that Windows will 
end up having a keyboard input framework with exactly the same performances as 
its challengers.

Marcel