From: Karl Pentzlin (karl-pentzlin@acssoft.de)
Date: Sat Sep 20 2008 - 11:30:19 CDT
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
http://www.its.se/ITS/REMISS/ITS_rem/tbstd-slutforslag.pdf ), and
the Canadian standard (about which information is found at
http://www.tbs-sct.gc.ca/its-nit/standards/tbits05/spec05a-eng.asp ).
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
standard.
It was also decided that there will be diacritical marks for
overstriking.
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
goals:
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.
functions).
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
layouts":
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:
http://www.europatastatur.de\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