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

From: Karl Pentzlin (
Date: Sat Sep 20 2008 - 11:30:19 CDT

  • Next message: Marcin 'Qrczak' Kowalczyk: "Re: Submission to ConScript Unicode Registry: Sylabica"

    Asmus Freytag wrote on the Unicode Mailing list 2008-09-19 01:08:
    AF> A diffuse, overblown, hard-to-master design helps no-one.

    I do not know exactly what this comment refers to.

    ISO/IEC 9995-3 is a standard which adds a second group to every
    keyboard design which declares conformance to it.
    At the present time, and according to the information I have until
    now, the only two national standards which do so are a Swedish
    standard (a draft is found [in Swedish language] at ), and
    the Canadian standard (about which information is found at ).

    While the Swedish standard is reported to me not actually being used,
    the Canadian standard is in fact be used (it refers in fact to a
    subset of MES-1, as it is in accordance with ISO/IEC 9995-3).
    You can buy keyboards in Canada showing the ISO/IEC 9995-3 characters
    on the right part of each key.
    There appears nothing diffuse, overblown, or hard-to-master to me to
    use these Canadian keyboards. On the contrary, the Canadian keyboard
    shows that the ISO/IEC 9995-3 way is a proven way to supplement a
    keyboard layout.

    In SC35/WG1, we had the following tasks:
    1. ISO/IEC 9995-3 in its present form has some deficiencies to be
       corrected anyway.
    2. There is a need to standardize keyboard input for more characters
       to satisfy international needs.

    We decided:
    1. To satisfy the international needs, we initiated a new work item
       called "ISO/IEC 9995-9", which is not bound to the specific
       mechanisms standardized in ISO/IEC 9995-3. Especially, conformance
       shall be claimable for a broader spectrum of keyboards than it can
       be done for ISO/IEC 9995-3.
    2. We decided about some minor changes to ISO/IEC 9995-3 as it is,
       to overcome the known deficiencies for its current users (i.e. the
       Latin-writing parts of Europe, and Canada) while maintaining
       compatibility to existing implementations.
       The most important change was to set up a new "current" common
       secondary group, but allowing claiming conformance by explicit
       reference to the "outdated" common secondary group which is still
       included in the standard, unchanged from the present version of the
       It was also decided that there will be diacritical marks for
       The exact list of the characters added to and reordered within
       the "current" common secondary group was not done directly in the
       SC35/WG1 meeting, but was appointed to me to be done before the
       distribution for CD ballot due to Oct 1.
       This was the reason for me to discuss this character list here
       (beside other places), wishing not to work in an ivory tower.

    Thus, the typical keyboard using conforming to ISO/IEC 9995-3
    continues to have two groups (main and secondary) supplying three
    levels each (in common language: unshifted, shifted and "AltGr").
    The complete layout can be engraved on the keys.

    Thus, a keyboard design following the updated ISO/IEC 9995-3 is clear,
    concise, and immediately to grasp.

    As a result of the mentioned decisions, the new version if ISO/IEC
    9995-3 provides a means to large parts of the world fulfilling the
    1. All names (personal and organizational) and texts written in
       official main languages of all countries can be written correctly
       (provided they use the Latin script).
    2. All names and text written in the most "minority" or "aboriginal"
       languages of at least some areas of the world can be written
       correctly (provided they use the Latin script).
       (e.g. Central Africa is not included for this time, as they
        use more letters than can be handled by the concepts defined
        in ISO/IEC 9995-3 – there ISO/IEC 9995-9 will be for.)
    3. It is possible to write typographically correct at the character
       level (this requires the inclusion of quotes, en/em-dashes, etc.).
    4. Transliterations of names from non-Latin scripts into Latin
       are supported at least for widely used languages.
       This is needed for geographical names, as well as to enable at
       least the larger religious groups to write their holy names
       (from Arabic, Hebrew, Sanskrit) correctly with due respect.
    5. As the "ancient looking" Latin script variants Fraktur
       (Blackletter) and Gaelic have contemporary use (besides hobbyist)
       e.g. in the advertising business, they are supported.
    6. Symbols used in common business usage are provided, like € or ®.
       (This may include some elementary mathematical characters like ≤;
       this is the "gray area" where decisions are at last taken according
       the availability of free places for allocation, and where the
       decision is to be made whether "arcane" [in the sense described
       below] input possibilities shall be provided).

    Having a keyboard with characters engraved, at least for the engraved
    characters there are no other input methods necessary. The user can
    see the way to input these characters directly by looking at the
    keyboard itself.

    Now, we can provide an exact definition for "arcane" in this context
    (as this term was introduced by Kent Karlsson in this discussion):
    A character is input in an "arcane" way if it is not engraved on the
    keyboard used. There are several degrees of arcanity: Entering
    combined characters by dead keys containing the diacritical marks
    followed by a key containing the base characters (the way fixed within
    the scope of ISO/IEC 9995-3) is "less arcane" (at least for users
    accustomed to dead keys anyway), while the input of "≤" by "macron
    below" + "<" is "more arcane".

    Of course, there can be input methods provided (like the IMEs
    existing for Chinese) for characters like U+2264 "≤", especially when
    it comes to select other variants like U+2A7D "⩽" or U+2266 "≦".

    Input methods are appropriate if the character is to be selected from:
    1. a large inventory (like Chinese, full math set, etc.), or
    2. an inventory which is not well known to the user (like Greek
       letters for someone who does not speak Greek, or Central African
       Latin letters for someone who wants to access the whole set
       instead of the few ones specific to a given language),
       if there is no direct access by keys having this letters engraved.

    Such input methods, however, require an interruption from continuous
    typing, and thus are less appropriate for restricted sets of
    characters which occur with some frequency in some kind of texts.
    This is especially a problem for touch-typists as well as for anybody
    who does not want to look at the screen at all while typing.

    Moreover - besides the fact that such IMEs are not subject of the
    ISO/IEC 9995 series of standards - IMEs imply minimum requirements
    to operating system software and display hardware, while standardized
    keyboards operate independent of any other hardware and imply no
    software requirements beyond the implementation of a relation from
    key actuation (resp. sequences of these) to characters (resp.

    As ISO/IEC 9995-3 can only include a restricted set of characters, there
    is no need to employ IMEs for these.
    Of course, the characters which at last are included in this standard
    should be selected as carefully as possible within the existing time and
    funding limitations: something I just am trying to accomplish.
    While "less arcane" character inputs are not avoidable (and are included
    in the present version anyway), "more arcane" ones should be introduced
    only if the gains outweigh the costs, especially as there is an ISO
    9995-9 on the horizon which probably will include such characters in a
    more consistent way. On the other hand, the costs appear low as nobody
    needs to know such "more arcane" character inputs; thus everybody
    who ignores them has no disadvantage compared to having this input
    possibilities not at all.

    Now coming to ISO/IEC 9995-9 "Multilingual, multiscript keyboard group
    This, at this time, is only an idea, consisting of two resolutions
    taken at the SC35 plenary in Naples 2008-09-12 and a paper found at:\material\ISO-IEC-9995-3-alternative-draft-9b.pdf
    which is already outdated in several points by the discussions we had
    in Naples. Thus, it is far too early to make any judgements about the
    outcome of this project.
    The mentioned paper, by the way, is nothing like hostile to IMEs:
    The way it handles IPA (phonetic characters) can in fact be regarded as
    a kind of IME.

    - Karl Pentzlin

    This archive was generated by hypermail 2.1.5 : Sat Sep 20 2008 - 11:35:34 CDT