Re: Keyboard Cursor Keys

From: Doug Ewell (
Date: Tue Nov 30 2004 - 00:01:46 CST

  • Next message: Doug Ewell: "Re: Relationship between Unicode and 10646"

    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

    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:

    > 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

    -Doug Ewell
     Fullerton, California

    This archive was generated by hypermail 2.1.5 : Tue Nov 30 2004 - 00:03:33 CST