A 18:39 97-07-29 -0700, Erik Fortune a écrit à unicode@unicode.org :
[anonymous quote] :
>> If ISO 9995 provides a reasonable set of codes for keys (I haven't seen
>> the standard myself yet), then it might be a nice idea to reserve some
>> small Unicode range (at least on Plane 1) for ISO 9995 key codes for
>> applications like keyboard drivers where characters and function key
>> events appear in the same data stream.
[Erik] :
>It provides a reasonable, if incomplete, set of codes. We might
>also want to look at X keysysms as another source of "key labels" --
>since X11R6.1, X includes keysyms for all of the ISO characters plus
>a bunch of other common and/or useful keys.
>
>In fact, I have a type 1 font that I created which has (poorly hinted
>but usable) representations of all of the symbols defined in iso9995-7.
>The font is freely distributable; drop me a note if you'd like a copy.
>
>-- Erik
>+-----------------------------+--------------------------------------------
--+
>| Erik Fortune (erik@sgi.com) | "To avoid hitting the bumper of the car in
|
>| SGI Globalization R&D | front, I struck the pedestrian.
|
>| ++1 415 933 1922 | -- Explanation from an accident
report |
>+-----------------------------+--------------------------------------------
--+
> All opinions are my own, so leave my employer out of this
[Alain] :
I'm trying to catch on with my hundreds of mesages still unopened since I
came back from vacation in the beginning of August and I found this
interesting question.
ISO/IEC 9995 is totally decoupled from coding. It establishes a system of
coordinates to describe keyboards, assigns graphical representations of
characters to keys of an international keyboard, requires a minimum set of
functions, it names functions, and even prescribes symbols for functions
where symbols are to be used (in international environments or multilingual
countries). Btw, there is also a famous part, part 8, which assigns letters
to keys of a numeric keypad -- for North American residents it should allow
you by default to be able to type Q and Z in 800 telephone numbers using
the 7 and the 9 [these letters are missing from old phone sets].
Having written many different keyboard drivers myself for PCs, I have to
say that one has to know how the current technology works (and it is
similar with IBM 327x terminals, with one extra step of decoding through
controllers): the keyboard sends a scancode (which on PCs can be a series
of scancodes for a given key -- compound by the fact that there are also
extented PC scan codes, i.e. depending on the mode, the same key can
generate different sequences) to the computer when the key is depressed and
another scancode (or series) when the key is released (this allows
controlling keyboard typing in real time, so that you can also make, say, a
sythesizer with your PC keyboard, where the duration of time you have your
finger on the key controls the duration of the sound being generated; I
have such a keyboard driver at home which makes my computer keyboard a piano).
In other words, when you type a key, a code is generated which corresponds
more or less to the position of the key on the keyboard for the first
generation of PC keyboards (with patches later on). This code has to be
translated into a character, which generally depends on the
country/language which you choose your keyboard driver for.
This also allows to make the same keyboards in different countries
(hardware-speaking), and to engrave them differently (IBM also had at some
point a system in which you just snapped a plastic keycap over the basic
skeleton key, which was brilliant). Keyboards were also made using LCD
display on each key which allow you to send the representation of the key
dynamically to each keytop from the computer (too expensive in 1988, it
could become a good tool with UNICODE, and the cost depends on the numbers
sold, it could be made cheap, just as you can buy LCD watches for 2 USD in
service stations -- and they make a profit!)
You could decide that a function key generates a code too (à la ISO/IEC
6429) but in general (and it is certainly the case on a PC), flag bits are
rather set in the computer to indicate a mode that keyboard drivers will
just monitor at a higher layer of the application (Caps mode [latching],
left Level-2 select, right level-2 select, right control, left control,
insert, scroll mode and so on).
One major problem with this system after 15 years of experience, is that
keyboards never stopped to evolve, and that applications, even at the scan
code level, do not have any idea of the position of the key on the
keyboard, even if they want to.
Now ISO/IEC 9995 could help as it describes keys in term of real
coordinates (key B10 being the / key on an American keyboard and É key on a
Canadian keyboard [this key is quite stable), and key D03 being the E key
on most European and American keyboards using the Latin script [this key is
pretty stable too]). It would be desirable that future keyboards identify
keys in these terms, that would solve many problems. In absence of LCD
keys, it would also be desirable that keyboards identify what set is
engraved on keys (that is a requirement if keyboards are to be portable and
"plug-and-play", how it is done is soemething else [there are many
economical ways to do this and we, in JTC1/SC18/WG9, have already seen
Japanese calculators in which you could completely scramble the detachable
individual keys, put the digits in any order in the matrix, and that still
worked as engraved on the keys -- DIP swiches automatically set by one
keycap could also be used], in particular for handicapped people who switch
to different environments). All these issues will be the object of a
Technical Report¹ in preparation in ISO/IEC JTC1/SC18/WG9 on future
keyboards and other input devices.
To end my article, let me tell you some good news about ISO/IEC 9995 and
UNICODE:
-there currently exists a full implementation of ISO/IEC 9995-3
(corresponding to conformance level 2b of Canadian standard CAN/CSA
Z243.200-1992) made by Microsoft. So far, only partial implementations
existed (subsets were allowed): my Canadian keyboard (the one I use on
all my machines, except that it is engraved only on my desktop machines,
I only use the driver on my portable²) supports the full Latin 1
repertoire (plus the OE ligatures of Windows and the upper case Y
DIAERESIS of Windows too), but it was limited to this set because the
character set technology was limited to 8 bits. Now the version of the NT
driver that Microsoft made because the Québec government requires group 2
of ISO/IEC 9995-3 (the Canadian government only requires French anf
English support, the Québec government requires full Latin 1 at least)
supports the full repertoire of ISO/IEC 6937, with a UNICODE coding. I've
used it, although it was only a prototype to be released with the next
version of NT (hopefully Windows 98 as well).
-UNICODE (well, ISO/IEC 10646) will have in its BMP the I.T. symbols
representing functions that are prescribed by ISO/IEC 9995-7. In current
UNICODE (and 1st version of ISO/IEC 10646) these symbols are only
partially encoded (ex. : the Level-2-select function symbol
[traditionally called SHIFT when we only had two levels on the keyboard]
is U21E7, i.e. the UPWARDS WHITE ARROW). Only mechanical typewriter
function symbols of the keyboard will be excluded, eventually put in
other planes of the UCS if it is ever done. The extra symbol added
in Amendment 1 of ISO/IEC 9995-7, to represent the Decimal Separator
*function* will also be encoded in UNICODE (so far there exists a
problem with this key that is implemented as a character entry key rather
than like a function on the numerical keypad: this is nonsense as this
is a function to tell the machine that data entry has terminated input
of the integer part of a number to begin the fractional part; this does
not depend on output representation of the number, like some spreadsheet
programs force us to live with *on input* in countries which switch back
and forth between different representations of the separator on output).
The use of symbols rather than text for functions is very useful in
multilingual environments. Documentation has to be provided and online
dispaly and search of the symbols as characters is also necessary.
-in addition to the font that Erik mentions for ISO/IEC 9995-7, Michael
Everson also made a TrueType font that supports it (Everson Mono
Keyboard) and that was used to prepare soem ISO documents, including
ISO/IEC 14755 on input methods to enter UCS (UNICODE) characters with the
help of any national keyboard (and other I/O devices).
-ISO/IEC 9995-7 keyboard symbols are used in other countries than Canada,
if you were ever wondering (used by Apple, used on portables made by or
for IBM worldwide and displayed with LCDs or embossed in plastic), and so
on.
-I will ask to revisit ISO/IEC 9995-3 at the next Cupertino meeting
of ISO/IEC JTC1/SC18/WG9 to be held in November to make room for the EURO
SYMBOL in the international layout (complementing efforts made in the
8-bit and multiple-octet character set technology world at the last
ISO/IEC JTC1/SC2 meeting in Crete in June).
Sorry fo such a long article. I hope it will help anyway.
Alain LaBonté
Québec
Project Editor, ISO/IEC 9995³ (8 parts), Keyboards
Project Editor, ISO/IEC 14755, Input methods to enter
UCS (UNICODE) characters
¹ ISO/IEC TR 15440, TR on future keyboards and other associated input
devices and related entry methods, editor: Yves Neuville, France
² a standard is also in preparation for Portable computer keyboards
(ISO/IEC 15412, edited by Jim Jackson, IBM UK, Scotland) as is one
for Segmented keyboard layout requirements (ISO/IEC 15439), edited
by Mark Goldstein, Australia
³ Official ISO/IEC 9995 coeditors of part 7 :
Bernard Chauvois, France,
Frederick Bealle, Canada,
and myself
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:36 EDT