Bob Hallissy wrote:
> >4) Text selections, cursor movements and mouse hit-testing
> are done in a
> strictly visual way, so they are more or less as easy as in non-bidi
> editing.
>
> My question is about strictly visual selection: I take this
> to mean that when I select a region of text, the selected area
> is contiguous on the display, but potentially discontiguous as
> far as the backing store is concerned, e.g:
> Backing store: quick wafting zephyrs VEX BOLD JIM
> Display: quick wafting zephyrs MIJ DLOB XEV
>
> Does strict visual selection mean that I can select "zephyrs
> MIJ" ?
Yes, generally speaking.
I haven't read many docs about bidi editing, but all of them agreed on using
a terminology similar to this:
- "visual selection": the selected block is contiguous on the display, but
potentially discontiguous in the backing store.
- "logical selection": the selected block is contiguous in the backing
store, but potentially discontiguous on the display.
Notice, however, that all this assumes that the backing store is in
*logical* order.
But we were talking about performing editing operations in *visual* order.
I.e., we were discussing running the bidi algorithm only one time, before
starting editing. Therefore, backing store and visual order are one and the
same, in this scheme.
The logical order would then be reconstructed at the end of editing (e.g.,
just before saving the file), by running a "reverse" bidi algorithm.
I haven't still very clear all the details of how this reverse bidi
algorithm could be. However, Mark Davis told us that there already is an
implementation of such an algorithm in ICU (http://oss.software.ibm.com/icu)
although, honestly, I haven't had the time download it and see how it works.
> I so, what happens when I then type a character to replace
> the selection -- does it end up between "wafting" and
> "VEX", or after "BOLD" ?
On the display, there is no doubt that it would go between "wafting" and
"DLOB" (there is no "BOLD" on the display!).
But one cannot say where the newly typed character will go in the logical
order: it depends on several things.
In the model that I have in mind, the display string is formed by *two*
arrays of information: one is the array of character codes (your "quick
wafting zephyrs MIJ DLOB XEV"), the other one is the array of embedding
*levels*.
Moreover, each paragraph has its own direction (the "paragraph level"),
independent of the embedding levels in the string.
It is the array of levels plus the paragraph level that determine where
characters will go in the reconstructed logical order.
As you have indicated both the logical and visual order in your example, it
is quite easy to infer a plausible set of levels:
Logical order: quick wafting zephyrs VEX BOLD JIM
Visual order: quick wafting zephyrs MIJ DLOB XEV
Levels: 0000000000000000000000111111111111 (paragraph
level: 0)
When you delete the block, this is what remains:
Logical order: (undefined while editing)
Visual order: quick wafting DLOB XEV
Levels: 00000000000000111111111
The new character that you enter is on the boundary between two "level
runs", so whether it will go in the LTR run or in the RTL one depends,
again, on the embedding level of the new character:
So, if you enter a RTL character it will be merged with level 1 run:
Logical order: quick wafting VEX BOLD X
Visual order: quick wafting X DLOB XEV
Levels: 000000000000001111111111
But if it is LTR, it will go in level 0 run, and it also causes the "reverse
bidi algorithm" to generate embedding controls because of the level of the
space on the right side of "x":
Logical order: quick wafting x<RLE>VEX BOLD <PDF>
Visual order: quick wafting x DLOB XEV
Levels: 000000000000000111111111
In my personal model, all characters coming from the keyboard are LTR or
RTL, including those which are defined neutral or weak in Unicode.
But in a model (Roozebeh's?) that also supports neutral characters on the
keyboard, there must be a rules to assign a level to neutral characters.
Logical order: (undetermined until the level of "%" is not
assigned)
Visual order: quick wafting ! DLOB XEV
Levels: 00000000000000_111111111 (paragraph level: 0)
This rules could be drawn by analogy from the Bidirectional Algorithm
itself. In this case (discordant levels on the two sides), it could be a
good idea to take the paragraph direction.
_ Marco
This archive was generated by hypermail 2.1.2 : Fri Jul 06 2001 - 00:17:15 EDT