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

[Philippe Verdy]

2016-11-04 18:03 GMT+01:00 Doug Ewell <doug at ewellic.org>:

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

It is the way it is documented in MSDN that explains the formats fo keymap
tables (you have to notice that there are several table formats, each
format allowing more or less code units.

You seem to only see the basic historic format (the one used in
Win16/Win9x) that only stores a single code unit, there are others, and
they are documented, includeing the fact that the values of table entries
are two kinds: either code units, or specific values for chaining to a dead
key table, and the spacial NULL value to fill gaps, because table entries
have a static length.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20161104/df922152/attachment.html>