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

Philippe Verdy wrote:

>>> the combined state can then
>>> accept the space bar to force the output of the NFC form for
>>> SPACE+diacritic1+diacritic2, which should be, if possible, a
>>> spacing-diacritic1 followed by a combining-diacritic2, or the
>>> reverse if both diacritics have a non-zero combining class but the
>>> second one has a lower combining clas than the second one).
>>
>> Even if true -- and I doubt that the Windows keyboard engine knows
>> anything about Unicode combining classes -- it doesn't solve Mats's
>> problem. He doesn't want to generate the two diacritical marks in
>> isolation. He could do that without dead keys.
>
> Windows does not have to know that: the order will be the one you have
> used in your keymap tables.

Then combining classes have nothing to do with this after all, and it
was misleading to mention them.

>> If a user types a dead key, followed by a character not listed in the
>> dead key table, Windows gives up and outputs the characters
>> associated with the two keys. That's not at all the same thing as
>> what Mats wants.
>
> Windows does not do that magically: for characters missing in a table,
> it uses by default the position assigned to the space bar, which must
> be mapped in all keymaps to generate a seuqnce for the "isolated" dead
> keys, then it will reset the state to initial, and then will try to
> find a mapping for that character from the table for the initial
> state.

Nope. Try typing <acute accent>, <b> on any Windows keyboard you like.
You will get 'b' followed by whatever base character is associated with
the <acute accent> dead key. This is often apostrophe or U+00B4, but the
space bar has *nothing to do with this*. It is the code point that has
the @ sign before it in the main LAYOUT table.

Here is a snippet you can actually copy and paste into a KLC file to
illustrate this:

<begin code>

LAYOUT ;an extra '@' at the end is a dead key
//SC VK_ Cap 0 1 2
//-- ---- ---- ---- ---- ----
28 OEM_7 0 0027@ -1 -1 // APOSTROPHE, <none>, <none>
30 B 0 b -1 -1 // LATIN SMALL LETTER B, <none>, <none>
39 SPACE 0 0020 0020 -1 // SPACE, SPACE, <none>
53 DECIMAL 0 -1 -1 -1 //

DEADKEY 0027
0061 00e1 // a -> á

<end code>

> Pseudo-code:
>
> Table[Initialstate] [<deadkey1>,<modifiers1>] = StateDeadKey1
> Table[StateDeadKey1] [<deadkey2>,<modifiers2>] = StateDeadKey1And2
> Table[StateDeadKey1And2] [<base letter>,<modifiers3>] =
> NFC(<base letter; deadkey1; deadkey2>)

This is not an example of how it actually works, which someone else can
duplicate. It is a description of how you imagine it works.

The chained dead key part is fine, as I said before, but the part where
NFC(<base letter; deadkey1; deadkey2>) adds up to two or more code units
is NOT fine. You can't do that. It won't compile the way you expect, if
at all. Try it and see, and send or post the *actual code* if you get it
to work.

> 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.

Very little of this is demonstrably true, such as the part where the
limit of 4 UTF-16 code units was somehow increased to 6, despite the
fact that Kaplan often said this had not happened. And dead key mappings
don't follow this at all; they are limited to ONE code unit.

Again, if you can't demonstrate otherwise, but can only assert it, you
may as well assert that the sun revolves around the earth.
 

--
Doug Ewell | Thornton, CO, US | ewellic.org