Re: Latin-script keyboard layout (was RE: Quick Question About Korean Input Methods)

From: Michael S. Kaplan (
Date: Sun Jan 03 2010 - 21:25:27 CST

  • Next message: Mahesh T. Pai: "Re: Latin-script keyboard layout (was RE: Quick Question About Korean Input Methods)"

    From: "Karl Pentzlin" <>

    > MSK> From: "Karl Pentzlin" <>
    > >> Microsoft Keyboard Layout Creator (V1.4) is definitely an outdated
    > >> tool.
    > MSK> I'd love to better understand this assertion....
    > For instance (please correct me if I have overlooked something):
    > 1. I cannot assign a SMP character as "composite" to a dead key
    > combination.

    A limitation of the Windows USER keyboard architecture. This hardly makes
    the tool "outdated".

    > 2. I cannot handle diacritics as dead key when the destination character
    > is not available as a precomposed character.

    Also a limitation of the Windows USER keyboard architecture. This hardly
    makes the tool "outdated".

    > 3. I cannot handle multiple diacritics as dead keys (considering applying
    > a single diacritic to a precomposed character a "bad trick").

    Also a limitation of the Windows USER keyboard architecture. This hardly
    makes the tool "outdated".

    > 4. I cannot work on a Japanese-like 106-key layout.

    The 106 key keyboard adds only one additional key that would be useful for
    letters/symbols, and adding it when it is unavailable on the vast majority
    of keyboards is a genuine usability issue. This hardly makes the tool

    > 5. I cannot define an ISO/IEC 9995 conformant Group Selection.

    Um, I guess. This makes the tool "outdated" in what way exactly? Any tool
    that does not support a particular ISO standard that Microsoft did not
    participate in and does not use to define or describe its keyboard layouts
    is "outdated"?

    > 6. I cannot import tables (e.g. text files or Excel sheets;
    > except hacking the Source File format).

    And this clear FEATURE REQUEST makes it outdated? Given the lack of any
    coherent format that can describe everything the source format requires,
    even now (years later!) I'd say this is more of a limitation of the format
    makers. :)

    > 2./3. simply require sequences of combined characters entered as dead
    > keys simply being reordered after the next character suitable as base
    > character, and then being reordered according to NFC or NFD when used
    > in a Unicode environment. (In fact, some special cases like use of
    > Backspace after a dead key may require additional rules.)

    Um, huh? The layouts do no such thing, and neither does the underlying
    architecture. Maybe this is something extra you are doing?

    > Please refer to the following documents to see what kind of keyboard
    > layouts are expected to be dealt with an up-to-date version of MKSLC:
    > 1.
    > (description of the revision of ISO/IEC 9995-3, currently in FDIS)
    > 2.
    > (NP proposal on ISO/IEC 9995-9: Multilingual, Multiscript Keyboard
    > Group Layouts)
    > 3. - Appendices 1
    > and 3
    > (the final version of this paper, with some editorial changes, is
    > submitted to CEN
    > for publication);
    > for more details about Appendix 3 see the "Five Scripts Keyboard":

    I've seen the doc, and I remain unimpressed. And I hardly find anything that
    fails to dance to a given tune as "outdated".

    > (Note regarding dead keys: People using a dead-key-free keyboard may
    > consider it appropriate to have diacritics entered in the Unicode
    > order, i.e. after the base character. Unfortunately, virtually all
    > keyboards for languages using the Latin script implement diacritics as
    > dead keys, as a heritage of the mechanical typewriters. Therefore,
    > ISO/IEC 9995-3 is bound to dead keys, while newer concepts like the
    > ISO/IEC 9995-9 draft employ both ways, leaving the choice to the
    > users.)

    Given the fact that it was the lack of support in a core platform
    architecture and the feedback from Microsoft on that point that led to the
    inclusion of the alternate method in the first place, I would say that the
    only thing "outdated" here is a notion that failing to support 100% of a
    standard that it was never intended to support is a flaw of any sort. The
    whole fanciful "user switching" notion, not supported anywhere, is
    standardese fantasy, not supported by any architecture AFAIK. It was
    originally a compromise to help bring existing architectures into the fold
    but then it went this other weird direction.

    ANYWAY, I really only originally took issue with your use of language in
    calling MSKLC outdated, but now I'd add that since I have read most every
    draft of the standard in question you have been citing that I have done my
    due diligence and that you could at least do the appropriate
    research/homework as a part of doing yours. :-)


    This archive was generated by hypermail 2.1.5 : Sun Jan 03 2010 - 21:29:01 CST