Dear friends,
Here is a summary of the discussion from my viewpoint.
1. Visual selection in a bidi context is not useful per se.
2. It would be useful to have a key-stroke sequence and the possibility of
toggling-icons in the margin of the text like <->, <<- and ->> that
control the display of the text between bidi, logical RTL and logical LTR.
This would allow the user to toggle the text from bidi display to
logical display for the purpose of doing a visual text selection.
3. It would be useful to have a caret with two flags, possibly one at the
top and one at the bottom. The top flag would show the display direction
as it does now, and the bottom flag would display the base direction. I
receive many questions from OOo users who see the period at the end of a
Hebrew sentence jump to the beginning of the sentence. I have to tell the
users to pay attention to the base direction indicator that OOo provides.
In contexts like Java-based applications where there is no external base
direction indicator, the extra flag on the cursor would help.
Best regards,
- yba
On Sun, 26 Oct 2008, Omer Zak wrote:
Date: Sun, 26 Oct 2008 09:31:36 +0200
From: Omer Zak <[EMAIL PROTECTED]>
To: linux-il <[email protected]>
Subject: Re: [YBA] Logical VS Visual Text Selection
I think that Dov's idea is good one, and I'd be happy to see an
implementation of his idea.
Questions, whose answers require experimentation and tweaking:
1. Do we display sources and sinks over all the document or only at the
ends of the span, in which the cursor is now?
2. Do we display them all the time (toggled by the user in the same way
spaces are explicitly displayed in some wordprocessors, by displaying
small dots instead of spaces), or only when the user tries to select
text (i.e. automatically)? And if automatically, how do we deal with
text displacement when sources and sinks show up/disappear?
3. Is this enough to make it easy to select text, or do we need also to
temporarily display text in logical-only ordering (see previous
discussion below)?
--- Omer
On Sun, 2008-10-26 at 09:20 +0200, Dov Grobgeld wrote:
Sorry to join the discussion so late, but I have an idea that I
believe would make both selection and caret position easier for the
user in a BiDi context. The idea is to visually display the points of
direction discontinuity. I like to call these a source when the two
directions diverge, and a sink when the two direction converges.
Heres an example:
Logical: abcABCabc
Visual with sources and sinks displayed: abc|><|CBA<||>abc
where |><| is a glyph indicating a sink point and a <||> is a glyph
indicating a source point. If a source and a sink meet they cancel
out. The user may now easily place the caret at the left or the right
side of the source and the sink points, which today is very difficult
to do.
I hope to create a concept implementation one day.
I'd be happy to hear comments about this idea.
Regards,
Dov
2008/10/7 Omer Zak <[EMAIL PROTECTED]>
Hello Jonathan,
I think I begin to understand what you are trying to
accomplish. It is
indeed difficult to precisely select a text segment when there
are
several spans of different directionality properties (LTR/RTL,
strong/weak, overrides, etc.) at its borders.
There are several possibilities for improving the selection
GUI
look&feel in this case:
1. Turn off BiDi ordering for the entire file (useful by
itself for
blind computer users; not directly related to our problem).
2. Manually turn off BiDi ordering for a text segment (say, a
paragraph)
and then manually turn it back on.
3. Use the metaphor of using one hand to straighten out a
piece of paper
when writing using the second hand (or straightening a piece
of cloth
while doing needlework): turn off BiDi ordering 5 glyphs
before and 5
glyphs after the mouse position (as the mouse moves, we
suppress
ordering of differing glyphs). Have them displayed with
background
having different color.
(The exact numbers are to be determined by usability tests,
and be
user-configurable through a setup menu. So is the background
color to
be used in this case.)
4. Have a small pop-up window, which displays the text around
the mouse
without BiDi ordering and let the user guide his mouse actions
using the
pop-up display. The regular text display would be unchanged.
It would be nice to get Arabic speakers to be involved in
this, as
Arabic presents a special problem - probably unreadable when
the order
of glyphs is reversed without additional processing. Hebrew
and Latin,
in contrast, are still somewhat readable even in reverse
direction.
--- Omer
On Tue, 2008-10-07 at 09:36 +0200, Jonathan Ben Avraham wrote:
> On Tue, 7 Oct 2008, Omer Zak wrote:
>
>> Date: Tue, 07 Oct 2008 09:23:32 +0200
>> From: Omer Zak <[EMAIL PROTECTED]>
>> To: linux-il <[email protected]>
>> Subject: Re: [YBA] Logical VS Visual Text Selection
>>
>>> From the discussion below, I understand that Shachar and
me use the same
>> definition of "visual selection". You drag the mouse from
column X to
>> column Y in the same row of the display, and get whatever
text which
>> happens to be displayed between those columns (the text
could have been
>> from different spans of the corresponding original text -
"logical
>> text").
>
> We agree on the meaning of visual selection.
>
>>
>> Jonathan, can you clarify if you mean the same thing, or
whether you
>> really meant "temporarily turn off BiDi ordering for a
selected text
>> segment and display it"?
>
> No, we mean temporaroly turn off bidi re-ordering for a
text, do a logical
> selection (which is now the same as visual selection) of
some subset and
> then revert the display of the whole text back to bidi
ordering. Selected
> text wold be always be displayed in the same ordering as the
unselected
> text.
>
> - yba
>
>
>>
>> --- Omer
>>
>>
>> On Tue, 2008-10-07 at 09:09 +0200, Shachar Shemesh wrote:
>>> Jonathan Ben Avraham wrote:
>>>> Right, that's what the qualifier "in effect" means.
>>>>
>>> Visual selection, to me, means "selecting text from a
continuous block
>>> of visually ordered text". If the text is not visually
ordered then the
>>> selection cannot be considered "visual". I conceded that
definitions may
>>> vary.
>>>
>>> I agree with Omer that visual selection does not seem all
that useful to
>>> me. I am at a loss to think of what use to the end user a
selection
>>> containing the end of the Hebrew part of a sentence
followed by the end
>>> of the English part of the sentence is going to be. Same
goes for the
>>> beginnings of the sentences combined.
--
EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il -
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
