Hello, Anne!

*** WARNING: longish comment, best left to readers really interested in bidi 
stuff ***

This problem is well known in bidi circles, and as far as I know, has not been 
solved satisfactorily, and maybe even has no good solution.
The heart of the problem is that a visually contiguous range may not be 
logically contiguous (i.e. contiguous in memory, or in DOM order), and 
vice-versa. If I am not mistaken, the number of disjoint visual segments 
corresponding to a contiguous logical range may reach 1 + twice the difference 
between the highest and the lowest embedding levels included in the range.
I am not sure about the other way around, i.e. how many disjoint segments might 
correspond to one contiguous visual range; I suspect that it is the same 
formula. Anyway, this is more than one, thus a challenge.

There is a long standing discussion between advocates of logical selection (the 
selection should be contiguous in memory but may be disjoint in display) and 
visual selection (the selection should be visually contiguous, but may cover 
disjoint segments in memory). Logical selection is often surprising and awkward 
to handle for the user. Visual selection is much easier for the user, but may 
arbitrarily glue pieces of text which are not logically connected, and would be 
heard not consecutively when you pronounce the sentence. I like to say that 
visual selection is an intuitive way to perform something which does not make 
much sense, and will seldom be useful (see Richard Ishida's request for use 

>From what I have seen, not many implementers have chosen to support visual 
>selection. I seem to remember that some versions of MS Word offered an option 
>to choose between logical and visual selection, and that the visual selection 
>was rather buggy.

So most implementations are of logical selection, but let us ignore the 
nonsense intrinsic in visual selection and consider how it should work in a 
copy/paste operation. The objective should be for the selected text to appear 
at the destination exactly as it is displayed at the source. To achieve that 
for bidi text, we might need to use directional hints, such as Unicode 
directional control characters, or markup. So the source application should 
know whether the destination application supports such directional hints, and 
which ones.
MS Word has an option whether to add control characters in Cut and Copy.

Even when using directional hints, there should be the minimum needed to 
achieve the proper display. It is not possible for the source application to 
determine this minimum without knowing the context of the destination. So the 
source application should bracket the selected text with enough directional 
hints to make sure it is displayed properly in whatever context exists at the 
destination, and the destination application should be smart enough to remove 
part or all of these hints if they have no visible effect where they are 
inserted. This is not impossible, but not simple either.

If the destination application does not support directional hints, the visual 
text should be transformed to the logical text which will give the same display 
without adding any directional controls. There are inherent problems:
- It is necessary to know the bidi embedding level (which in simple case is the 
paragraph direction) at the destination.
- Some visual configurations cannot be the representation of any logical 
sequence without the help of directional controls. For instance the visual 
string "abc DEF 123" in a left-to-right context, with "abc" representing LTR 
text and "DEF" representing RTL text.
An example in right-to-left context could be the visual string "123 abc DEF".

I hope this helps.

Shalom (Regards),  Mati

-----Original Message-----
From: Anne van Kesteren [mailto:ann...@annevk.nl] 
Sent: Saturday, August 15, 2015 8:20 AM
To: Ryosuke Niwaa 
Cc: public-webapps; Ehsan Akhgari; Aryeh Gregor; public-editing-tf; 
Subject: Re: Copying multi-range selection

On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa <rn...@apple.com> wrote:
> We've been recently exploring ways to select bidirectional text and content 
> that uses new CSS layout modes such as flex box in visually contagious manner.
> Because visually contagious range of content may not be contagious in DOM 
> order, doing so involves creating a disjoint multi-range selection.  There 
> has been quite a bit of discussion about how we can better expose that to the 
> Web since the current model of exposing a list of Range objects doesn't seem 
> to be working well.
> However, another important question I have is how copying such a selected 
> content work?  Do we just stitch together disjoint content?  But that may 
> result in the content being pasted in completely different order.

I copied www-international. Somewhat curious if this problem has been studied 
before. It does seem like you would have to add/remove formatting code points 
as the context where you paste may be different from the context where you 
copied from.


Reply via email to