From: Peter R. Mueller-Roemer (email@example.com)
Date: Tue Nov 30 2004 - 08:42:28 CST
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
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