Re: [OT] character collection for an international keyboard layout (ISO/IEC 9995-2 and 9995-3)

From: Karl Pentzlin (karl-pentzlin@acssoft.de)
Date: Thu Dec 20 2007 - 07:59:52 CST

  • Next message: Ed Trager: "Re: CLDR Usage of Gregorian Calendar Era Terms: BC and AD -- Can we please have "CE" and "BCE" ?"

    Am Donnerstag, 20. Dezember 2007 um 10:35 schrieb Asmus Freytag:
    AF> ... For people that speak a given language,
    AF> learning to type the (limited set of) additional characters for that
    AF> language is a manageable task, and the convenience of having a
    AF> particular "universal" keyboard layout available on any workstation in a
    AF> large organization (and not just on their own desk) can be a benefit.

    This is the main goal of my proposal to define a set of characters
    which is the base for an international Latin scrip keyboard layout.
    It is to have a standardized keyboard not only within an organization
    but universally. Thus, anybody can type in their languages and the
    languages they need e.g. for their business contacts.

    As everybody needs only to know a few languages (except for linguistical
    contexts), they (as you said) only need to know how to type the few
    extra characters which these language require.
    Thus, the user is in no way burdened by the possibilities for the
    language they do not need.
    When such a keyboard is universal, it is easy for anybody to get the
    initial help as the way to type the extra characters is universally
    standardized. This is what standardization is for.

    AF> ... The problem with keyboards that
    AF> command a very large set of characters is that typists have problems
    AF> remembering the key-bindings.

    Nobody has to learn anything what they do not need.

    I compare a keyboard to a musical instrument like a recorder. Every
    child can play a lullaby which only uses the c-d-e-f-g notes. If you
    want to play ambitious music, you have to learn some more finger
    positions. But the existence of these do not burden in any way the
    child playing its lullabies, the child does not even need to know that
    any of such complicated finger positions exist.
    But if you want, you can play ambitious music with a simple instrument.

    Internationalization is ambitious music, in this sense. If you don't
    need it, you don't need to know about it.

    Likewise, good typography is ambitious music in this sense. If you
    want continue to type ASCII, you can do so, and you do not even need to
    know that there are other dashes beside U+002D.
    But if you want to use the correct dashes (and quotes, slashes, tildes,
    ...), they are there, in a standardized way.

    Furthermore, managing a quite large set by a keyboard layout of course
    requires appropriate assignments to "levels" and "groups", together
    with carefully done key label design. This are areas which I do not
    have touched until now in this discussion.
    The label design must be in a way that it does not irritate the user
    who does not need anything special, but helps the user to find and
    learn the specific few key combinations they need or want.

    AF> However, when it comes to typing mathematics, it's not clear that this
    AF> is the correct approach. The number of symbols needed is too large and
    AF> their use is too varied for most users ...
    AF> ... as a result, you are
    AF> better off simplifying the design to what is needed for natural
    AF> languages (including the needs of commercial/legal documents).

    This is absolute correct.
    At first glance, I saw the set of mathematical characters in MES-2 as
    a subset suited for something like "ordinary school mathematics" (I
    did not found any information about the intent or the specifications
    for MES-2).

    But one important difference between mathematical and other text is:

    - Writing text in your language (or that of your business partners) is
      an everyday task. Once you have learned the few keys you need, you
      will continue typing in that way regularly without having to look up
      any new key combinations; having to use look-up tables or other
      special tools is an impediment of your daily work.

    - Likewise, if you have decided to type in a typographically ambitious
      way, you once learn the few (about 20) dashes, quotes and other
      special characters you need. After this, having to use look-up tables
      or other special tools is an impediment of your daily work.

    - But if you type a text containing maths (e.g. doing your school
      homework), you need access to a large character set from where you
      have to select the characters needed for your specific task, which
      is rarely the same over a series of task. Thus (besides the fact
      that you mostly need a formula editor anyway), in almost all cases
      you need a look-up table or another special tool anyway.

    Thus, I agree with you that there is no need to include all
    mathematical symbols of MES-2 into a keyboard layout set.

    However, there is a small set of mathematical and technical characters
    which are needed in everyday business correspondence (as my main job is
    to develop business software, I am familiar with this).
    (For such characters, having to use look-up tables or other special tools
     is an impediment of your daily work also.)
    To my experience, this set includes (besides the characters contained
    in "ASCII" U+0020...U+007E; excluding arrows for this time):
      U+00B0 DEGREE SIGN
      U+00B1 PLUS-MINUS SIGN
      U+00B2 SUPERSCRIPT TWO
      U+00B3 SUPERSCRIPT THREE
      U+00B5 MICRO SIGN
      U+00D7 MULTIPLICATION SIGN (typographical correct alternative to
        the in fact mostly used U+0078 "x")
      U+03A3 GREEK CAPITAL LETTER SIGMA (for sum or summation. U+03A3 fits
        into running text, contrarily to the larger U+2211 N-ARY SUMMATION
        inherited from the Mac charset)
      U+03A9 GREEK CAPITAL LETTER OMEGA (as Ohm sign; U+2126 OHM SIGN
        has a canonical equivalence to U+03A9, thus according to Unicode
        preference the latter is to be used)
      U+2030 PER MILLE SIGN
      U+2205 EMPTY SET
      U+2206 INCREMENT (used also for "difference")
      U+221E INFINITY
      U+2245 APPROXIMATELY EQUAL TO
      U+2260 NOT EQUAL TO
      U+2264 LESS-THAN OR EQUAL TO
      U+2265 GREATER-THAN OR EQUAL TO
      U+226A MUCH LESS-THAN
      U+226B MUCH GREATER-THAN
      U+2300 DIAMETER SIGN

    Thus, this reduced set continues to be approproate for inclusion into a
    keyboard layout.
    (Did I miss some character which is common outside Germany?)

    AF> ... and give enough information to help avoid misidentification
    AF> among similar characters.

    This problem has to be adressed when the layout itself and the key top
    label design is to be made (as far as the keyboard layout itself is
    concerned).

    E.g., the average user in the office may not distinguish between
    ogonek, cedilla and comma below. I have adressed this problem for my
    "Europatastatur" design by adressing a diacritics key "comma-thingie
    below" (see http://www.europatastatur.de/presentation1/5.htm ).
    [In ISO 9995-1 terminology, the key thus is a "group selector" rather
     than a diacritics key.]

    AF> For users that need to enter names and other information in native
    AF> spelling, i.e. in languages that they are not familiar with, the problem
    AF> is that locating a key on a keyboard (even a virtual keyboard) can be
    AF> more cumbersome than using a well-designed pick-list, for example.

    This applies only on the very first use (or for the cases where
    someone is really confronted with names from a lot of languages, e.g.
    when compiling a reference list for scientific work).

    Having the keys standardized does not prevent the use of other tools,
    especially such ones which teach the user how to type in the future
    without further impediment.

    On the other hand, any additional tools must be available to the user
    at first. This requires:
    - These tools must be available for your special hardware and
      operating system.
    - You must be able to acquire the tools when you become aware of their
      need. This is a real problem in any larger company or organisation
      where you have to go through bureaucracy and budget discussion.
    - You must be allowed to use the tool. This is a real issue in larger
      companies where an overworked system administrator simply disallows
      any additional tools, as he does not want any security risks and
      refuses to discuss the fact that this special tool has absolutely no
      security risk.
    - The user must have the knowledge and affinity to use the tool.
    This list may seem silly but reflects my experience, as I have tried
    in vain to introduce simple file compression tools at some of my
    customers.

    Thus, having a *standardized* tool at hand (like a keyboard with
    appropriate layout) is really an economic factor.

    AF> Hope you find some of these thoughts useful as you begin your active
    AF> contribution to the standardization process.

    Thank you very much for your comprehensive comments.

    AF> PS: an aside on MES-1 and MES-2. The criteria by which these were
    AF> designed have always seemed less than satisfactory. But apart from that,
    AF> the real issue with these collections is that, at best, they are sets
    AF> for "systems coverage", that is, sets that a system is supposed to
    AF> support for input, processing and display - but from that it doesn't
    AF> follow that they are the proper sets to consider for _keyboard_ input at
    AF> the exclusion of other forms of input methods.

    To this I totally agree, but nevertheless the actual wording of ISO/IEC 9995-2
    and -3 explicitly declare MES-1 as base for a standard layout.
    Something which is to be changed.

    - Karl Pentzlin



    This archive was generated by hypermail 2.1.5 : Thu Dec 20 2007 - 08:02:12 CST