Re: Keyboard Cursor Keys

From: Peter R. Mueller-Roemer (pmr@informatik.uni-frankfurt.de)
Date: Tue Nov 30 2004 - 08:42:28 CST

  • Next message: Michael Everson: "Re: Relationship between Unicode and 10646"

    Doug Ewell wrote:

    >Robert Finch wrote:
    >
    >
    >>'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.
    >
    the "easy" cases like adding character codes for cursor control functions
    are not so easy when you have a short phrase or R-text (Right-to Left) embedded in a line of Englisch (L-text).

    I think it is an acceptable solution at present (only a temporary implementation or solidified standard (?)) that the R-arrow will move through such a line of L-R-L mixed unicode text from Left, = Start of line, to Right, = logical End of text, passing the R-text in the correct logical order from its Right beginning to its Left end to continue past its Right in the usual manner. I would not like to give up this repeat-key action!

    If the text-program forces somehow the visually correct RtL direction on the L-arrow which is logically toward the logical end, while over R-text it would have a problem at the L-END of the R-Text, moving on to the visually next L-text it would continue in the logically prossibly not intended direction to its beginning.
    The R-arrow with cursor at the L-start of R-text should move the cursor visually correct to the beginning of the rest of L-text or logically correct to the previous L-text?

    I guess this ambiguity of intention let the text-programs provide LtR and RtL entry of text only to be changed for a whole paragraph. But that has presently undesirable effects on a mixed-direction line: L-jutified text becomes R-justified and sometimes the R-text moves into unexpected places.
    I am glad I don't have to make this switch (interrupting touchtyping twice in one line).

    Thinking of the horizontal arrow-keys as logically previous and next helps. Same for BS-erase and Del ('character under the cursor' is outdated, since the cursors usually are seen between characters nowadays.

    >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"?)
    >
    >
    MSKLC .exe helps to create your own keyboard-layout, and provides with
    the 'Swiss-German' keyboard the opportunity to assign to the 'normal'
    keys quite a few extra symbols in CAPS-mode. I think such
    keyboard-layouter should provide the possibility to make your own
    choice on how the arrow and other controll-keys behave for your own
    keyboard layout.

    Besides the directionally neutral SPace in Unicode, we need either a
    standard for text-programs, that forbids SPace after R-text to make the
    cursor jump past the R-beginning of R-text assuming that L-text will
    follow. I find it extreemly irritating if this happens before I have
    swiched to L-text-entry. New Unicode characters of explicitely
    directional R-, L- and or PDF-SPace would solve my problem with the
    present layout-possibilities. This would not be control-codes, because
    they would have not only a visual effect on the cursor, but rather would
    provide a way to disambiguate the neutral SPace.

    MSKLC.exe should provide key-assignments to e.g. seldom-used
    combinations of the F1..F12, Num- and Scroll- Lock-key with e.g. AltGr
    so select other keyboardlyouts and languages. I do not see how it could
    solve the above bidi-space-cursor problem without unidirectional SPace-code.

    >If you want to use characters to accomplish cursor control, you really
    >should take a look at the ECMA standard mentioned above.
    >
    >
    And how can MSKLC or you make the keyboard generate the desired control ?

    Peter R. Mueller-Roemer



    This archive was generated by hypermail 2.1.5 : Tue Nov 30 2004 - 08:46:45 CST