Re: Character list for European and Canadian use in the revised keyboard standard ISO/IEC 9995-3, supplementing MES-1

From: Asmus Freytag (
Date: Thu Sep 18 2008 - 18:01:48 CDT

  • Next message: Asmus Freytag: "Re: Character list for European and Canadian use in the revised keyboard standard ISO/IEC 9995-3, supplementing MES-1"

    On 9/18/2008 3:30 PM, Karl Pentzlin wrote:
    > Am Donnerstag, 18. September 2008 um 18:08 schrieb Asmus Freytag:
    >>> 2008/9/17 Karl Pentzlin <>:
    >>>> Elementary mathematical symbols:
    >>>> U+2264 LESS-THAN OR EQUAL TO - no own key needed, enter as:
    >>>> diacritical mark "combining macron below" + "less-than sign"
    >>>> U+2265 GREATER-THAN OR EQUAL TO - no own key needed, enter as:
    >>>> diacritical mark "combining macron below" + "greater-than sign"
    > AF> ... What's needed is another layer of software that is akin to a
    > AF> (much simplified version of an) Asian Input Method Editor. Such an IME
    > AF> will take multiple keystrokes and compose them into the correct symbol.
    > This is outside the means provided by ISO/IEC 9995-3, which only uses
    > diacritical marks to "combine graphical symbols".
    Keyboards do have certain limitations and that is only proper. While
    keyboards modeled more or less on the typewriter model are too
    restrictive, as all of us in this discussion agree, even the more
    generalized, multi-level keyboards are not as flexible as generalized
    input methods.

    The latter are able to use a wider array of key-stroke sequences, which
    may even be mnemonic, to access a nearly infinite number of characters
    (certainly the Han input methods can access tens of thousands of
    characters). For symbols, the repertoire is more limited, but there are
    well over a thousand, if not double that number.

    An input method that is modeled after the Asian IMEs and which would use
    the existing support in properly internationalized operating systems and
    applications would allow the user to map mnemonic sequences like \int
    for the integral sign, for example, or allow the user to type \int
    followed by a special key that brings up a list of all variations of
    integrals for quick selection.

    For some key seqences, if a user "always" makes the same selection from
    such a pick list, the IME can automatically re-order the choices, or
    even make the most common one the default. Such adaptive behavior is
    only possible because an IME has a user interface that lets the operator
    interact with the software while using it. Keyboard drivers normally do
    *not* provide such UI, and applications expect final form input from them.

    The key advantages of using such a more flexible system are the
    combination of mnemonics (potentially also customizable) with adaptive
    behavior, and much larger repertoire. Because the repertoire that an IME
    can handle is so much larger, the support of characters can be made more
    systematic and avoids the use of "tricks" - which look cute on paper,
    but prove difficult to master and retain in practice.

    In order to properly design a keyboard, one needs to be aware of the
    spectrum of input methodologies, so that it's possible to relegate
    problems that don't fit the methodology of keyboard input to another
    layer of software - even if that layer still needs development and is
    finally developed in another context.

    > A new ISO/IEC 9995-9 will probably more flexible.
    > For ISO/IEC 9995-3, there only the 47 unused places in Level 3 of the
    > common secondary group can be filled, two of them have already to be used
    > for the disintegration of the "or"s for two current key allocations.
    > Raising the number of characters which can be added beyond that
    > resulting number of 45 obviously requires some tricks, like the
    > "arcane" way listed for U+2264/2265.
    > The question is: should such characters included by such "tricks" now,
    > or not at all (i.e. be left for a later ISO/IEC 9995-9 which, whatever
    > its final shape will be, will allow multiple groups)?

    I think my comments above answer these questions.

    > - Karl Pentzlin

    This archive was generated by hypermail 2.1.5 : Thu Sep 18 2008 - 18:03:41 CDT