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

From: Karl Pentzlin (karl-pentzlin@acssoft.de)
Date: Mon Jan 04 2010 - 19:37:45 CST

  • Next message: Doug Ewell: "Re: Latin-script keyboard layout (was RE: Quick Question About Korean Input Methods)"

    Am Montag, 4. Januar 2010 um 04:25 schrieb Michael S. Kaplan:

    >> From: "Karl Pentzlin" <karl-pentzlin@acssoft.de>
    >> Microsoft Keyboard Layout Creator (V1.4) is definitely an outdated tool.
    >> For instance (please correct me if I have overlooked something):
    >> 1. I cannot assign a SMP character as "composite" to a dead key combination.

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

    In fact, I tried to answer in short, thus I did not provide a detailed
    discussion differentiating between the tool itself and its applicability.

    Thus, my claim of "outdated" applies to the process to generate
    keyboard layouts by MSKLC V1.4 as a whole.

    It does not bother me whether the "Windows USER keyboard architecture"
    or the tools to work with it are outdated. The whole thing is outdated
    in an inacceptable way as long as it does not support SMP characters
    completely and without restrictions (independently of my other points).

    When the Unicode committee tells proposers e.g. of the Hungarian Runic
    script that there is no problem to encode the script in the SMP for
    good reason, either all members of the committee (including Microsoft)
    have to do their homework (in this case: enable them to implement
    their keyboard layouts without any SMP-related problems), or they are
    liars.
    (I get especially angry on this point as I had several personal
    discussions with the representative of the Hungarian NB, to convince
    him that there are no problems when he agrees to have their script
    encoded in the SMP; thus the accusation of being a "liar" includes myself.)

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

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

    As said, I want to design keyboard layouts, not to adhere to any
    architecture, especially one for which I did not manage to find any
    documentation by reasonable means.

    Maybe you know the old joke:
     Q: How many engineers are required to change a burnt-out light bulb?
     A: None, if you declare darkness being the industry standard.
    The original version of this joke is attributed to "Microsoft
    engineers", but in fact none of the Microsoft employees I met at ISO
    meetings or elsewhere showed such an attitude.
    However, I see this attitude in the way you recur to the "Windows USER
    keyboard architecture" here.

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

    MSK> Also a limitation of the Windows USER keyboard architecture.

    Again - MSDN, Bing, and Google unanimously say:
    No Results Found For: "Windows USER keyboard architecture"
    (Maybe you can provide a link to a concise description?)

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

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

    Maybe "incomplete" is more appropriate than "outdated" here.
    The 106-key keyboard obviously has 4 keys more than the 102-key one,
    and please let the layout creator decide which keys they consider useful
    for whatever purpose.
    Of course there is no problem if a tool is restricted to the needs of some users
    only (even if this group is considered being the vast majority), if at the same
    time another tool is offered to the experts (I even would pay for it).
    But there apparently is only one MSKLC, thus I can expect it to handle a
    keyboard which is in fact available as an industry mass product for
    127 million users (inhabitant count of Japan).

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

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

    In fact, here "defective" is more appropriate than "outdated".
    An international standard is an international standard (especially if
    in fact there are national standards which adhere to it, as e.g. the
    Canadian one), whether Microsoft or any other company participates in
    its development or not.
    Microsoft is to be praised for its engagement in providing localized
    variants of its operating system and other software, thus supporting
    the cultural diversity. It is a pity that the company did not accept
    the invitation to participate in the special area covered by ISO/IEC
    SC35/WG1, to support their own goals there.

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

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

    Admitted.

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

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

    This depends on the definition what a layout is. Is it only a
    description of the keytop engravings, or does it include the exact
    function of its keys? I, admittedly, adhere to the latter interpretation.

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

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

    Sorry, I have difficulties to understand this. I assume that you refer
    to the preceding paragraph cited from my previous mail, referring to
    dead-key vs. Unicode-order input of diacritics. Unfortunately, I am
    quite new in the SC35/WG1 business and do not know very much of its history.
    What "lack of support" and "alternate method" do you refer to?
    By "user switching", do you refer to the possibility to switch between the
    two mentioned input methods for diacritics?
    By "compromise" and "weird direction", do you refer to the "dead key" method?

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

    What, exactly, are you missing?

    - Karl



    This archive was generated by hypermail 2.1.5 : Mon Jan 04 2010 - 19:40:54 CST