From: Doug Ewell (dewell@adelphia.net)
Date: Tue Nov 30 2004 - 00:01:46 CST
Robert Finch wrote:
> I see that there are no Unicode characters assigned for cursor/edit
> keys other than that which were originally in ascii ('return', 'tab',
> 'backspace', 'delete'). Could keys like 'cursor left', 'cursor up',
> 'Home', etc. be incorporated somewhere within the standard ?
These are not in Unicode because they are not related to representing
text, as such. Unicode is, above all, a standard for encoding
characters that are used to write text.
The only control characters in ASCII that directly relate to text
representation are CR, LF, HT, VT, FF, perhaps BS and DEL, and arguably
BEL. In the C1 zone, NL is also important in some environments. ESC
and maybe CSI are needed for implementing ISO 6429-style control
sequences. And of course, you have to have NUL! But that's pretty much
it for text.
The entire C0 and C1 repertoires were grandfathered into Unicode for
compatibility, but the only other control codes that have been added to
Unicode deal directly with text representation. These include
unambiguous line and paragraph separators (intended to replace CR and/or
LF, but not in common use), formatting characters such as joiners and
bidirectional aids, variation selectors, and a few script-specific
things.
Character-based cursor command languages such as "curses" were clever
and handy in the days of character-based user interfaces, but have
become less popular as GUIs have largely taken over. The character
model has never really been extended to include mouse movement, clicking
and double-clicking, etc.
If you are working with terminals or other character-only systems, it's
hard to beat the ISO 6429 model. You can download a free copy of the
equivalent European standard ECMA-48 at:
http://www.ecma-international.org/publications/files/ecma-st/ECMA-048.pdf
> I know this probably goes against the ideal that Unicode is simply a
> font (ug wrong word here) mapping. But it would make the standard more
> practically applicable.
No. Not a font mapping at all. What you are probably trying to say is
that Unicode deals primarily with visible characters, which is closer to
the truth.
> I'm trying to implement a Unicode keyboard device, and I'd rather have
> keyboard processing dealing with genuine Unicode characters for the
> cursor keys, rather than having to use a mix of keyboard scan codes
> and Unicode characters.
This will quickly spiral out of control as you move past the "easy"
cases like adding character codes for cursor control functions. What
about Shift and Caps Lock? That would make text representation
ambiguous; you don't want an 'A' created by pressing the A key while
holding Shift to be different from an 'A' created by pressing A with
Caps Lock enabled. (How would you represent "enabled"?)
What about the Ctrl and Alt keys (or equivalents in Mac and other
platforms)? What about Num Lock and Scroll Lock? F1 through F12 (or
whatever)? And (dare I mention them?) the Windows and Windows Menu
keys? This last example shows that the set of possible keyboard keys is
open-ended and subject to manufacturer whims. Laptops have all sorts of
unusual shifting keys not seen on "conventional" keyboards.
If you want to use characters to accomplish cursor control, you really
should take a look at the ECMA standard mentioned above.
> If there is an extended standard of some kind (eg UTF-16 ?) that
> supports this, could someone please point me to it.
Don't understand the reference to UTF-16 here. UTF-N, for any value of
N, is a way of representing the character codes of Unicode using
sequences of N-bit units. None is an "extension" of the Unicode
standard.
-Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
This archive was generated by hypermail 2.1.5 : Tue Nov 30 2004 - 00:03:33 CST