User:Uri/Bidi editing: Difference between revisions

User:Uri/Bidi editing (view source)

Revision as of 20:17, 19 August 2005

3,574 bytes added , 19 August 2005

→‎Problems with the current implementation

Uri

67

edits

@@ Line 75: / Line 75: @@
 These problems, as I see it, are all a result of the system's need to maintain an internal "logical" representation of the caret position, while presenting a visual interface to the user.
+==A proposal for an alternative system==
+In this section I'll present an alternative approach to implementing bidi editing (with visual caret movement). I won't go into implementation details, but I'll sketch the basic principles.
+The system I propose has two modes: '''logical mode''' and '''visual mode'''. The system is placed in logical mode following any logical function perofrmed by the user (such as typing or deleting), and is similarly placed in visual mode following any visual function performed by the user (such as pressing arrow keys, or clicking anywhere in the text).
+When the system is in logical mode, it stores the location of the caret "logically", i.e. as an offset to the (logically stored) text. When it is in visual mode, it stores the caret location visually, i.e. relative to the text as it is presented on the screen.
+While the system is in logical mode, and the user performs logical functions, the system operates very much like the current one: typed in characters are inserted at the logical insertion point; pressing "delete" (or "backspace") deletes the character logically following (or preceding) the current insertion point.
+Since the caret has to be drawn on the screen, its visual position must be determined following each logical function. This is done as with the current system - using IBM's algorithm (or a somewhat simplified variant thereof).
+When switching from logical to visual mode (that is, when the user performs a visual function while the system is the logical mode), the visual position of the caret is determined as above, and becomes the base position for the performed visual function.
+While in visual mode, only the visual position of the caret is tracked. Performing visual functions at this mode is simple (the caret is moved using a visual representation of the document), and no visual-to-logical or logical-to visual mappings are performed.
+When switching from visual to logical mode, the logical position of the caret is determined based on its stored visual position ''and on the logical function which is performed''.
+The last point is at the heart of this system, so I'll elaborate on it:
+Let's take our example of '''latinHEBREWmore''' again, displayed as '''latinWERBEHmore'''. Suppose the user visually moved the caret to between the '''n''' and the '''W''' (i.e. by using the arrow keys or the mouse). Now, suppose the user types an LTR character ('''x'''). The system has to switch to logical mode, that is, to map the visual position to a logical one. As we recall, this is ambiguous: the logical positions after the '''n''' and after the '''W''' both correspond to the current visual position. However, since at this stage the system knows that the user typed a LTR character, it will prefer the logical position following the '''n''', and the result would be logically '''latinxHEBREWmore''' and visually '''latinx|WERBEHmore'''.
+Conversly, if, at the same visual location, the user types an RTL character ('''X'''), the system will prefer the other logical position mapped to this visual position, and the result will be logocally '''latinHEBREWXmore''', and visually '''latin|XWERBEHmore'''.
+In both cases, the result will be likely what the user expected. Notice that we are able to do this because unlike the current system, which tries to "guess" what character the user will type next (based, e.g., on the keyboard layout), the proposed system only resolves the visual-to-logical ambiguity when it has all the information, i.e. when it knows what character was, in fact, typed in.