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 cases). >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; www-internatio...@w3.org 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. -- https://annevankesteren.nl/
