Dov Grobgeld submitted the following example (with visualization of source
and sink points):
Logical: abcABCabc
Visual with sources and sinks displayed: abc|><|CBA<||>abc
Just to show how niggling I am, let me modify the example as follows:
Logical: abcDEFxyz
Visual with sources and sinks displayed: abc|><|FED<||>xyz
Reasoning: there are enough letters in the alphabet, so that we don't have
to reuse any, which creates potential for confusion.
Now that the stage is set, let's address the proposal itself. It is
interesting and may help users who could not guess otherwise where the
"points of direction discontinuity" (which I like to call "boundaries")
are located. But the presence of the source/sinks markers does not really
make easier the gymnastics of locating the caret on the desired side of
the boundary.
Let's assume the current state of things, where the display is: abcFEDxyz
If a user wants to extend the "abc" run, all he/she has to do is to click
on the right part of 'c', and the caret will be logically after 'c'. If
the user wants to extend the "FED" run, he/she should click on the left
part of 'F', and the caret will be logically after 'F'. Similar
operations apply to the boundary between 'D' and 'x'. Unless the font is
quite small, or the user has motor difficulties (which is not to be
neglected), the source/sink markers are not needed, IMHO, and there is no
justification for the added complications caused by their presence (see
questions raised by Omer Zak).
If the font is too small for conveniently clicking on the needed half of a
glyph, it is always possible to move the caret anywhere in the run which
is to be extended, and then to use the left/right arrow keys to reach the
boundary on the proper side. For instance, in order to extend "FED",
click anywhere within that run, then press the left arrow until the caret
is positioned on the left side of 'F'.
All the above should work in the current user interfaces on most any
platform (please let us know if you are aware of exceptions).
There is an issue which is not solved by my little tricks: it is the case
of "double boundary". Let me explain with an example.
Logical: abcDEF345xyz
Visual with sources and sinks not displayed: abc345FEDxyz
If we consider the boundary between 'c' and '1', there are 3 possibilities
for adding characters at this point:
1. as extension to "abc" (for instance to form "abcmn")
2. as addition at the beginning of "345" (for instance to form "12345")
3. as extension to the combined visual run "345FED" (for instance to form
the visual run "HG123FED").
Since we have 3 possibilities, a binary choice like being on the left or
right side of the boundary is not going to enable all 3.
With Dov's source/sink markers, we may have something interesting:
Logical: abcDEF345xyz
Visual with sources and sinks displayed: abc|>|<|>345|><|FED<||>xyz
With such a visualization, case 1 would be selected by clicking somewhere
on the leftmost |>, case 2 would be selected by clicking on the second
(from the left) |>, case 3 would be selected by clicking on the leftmost
|<. This offers a solution to my double boundary use case, but the amount
of source/sink markers within the text becomes cumbersome.
And a suggestion: for the sake of consistency and completeness, may be we
should have (adding marks at start and end of runs):
Logical: abcDEFxyz
Visual with sources and sinks displayed: |>abc|><|CBA<||>abc|>
Omer Zak asked:
"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?"
My answer is that you must display sources and sinks all over the
document, because an essential goal of this feature is to facilitate
selection. To select, you have to click on the starting point, then on
the ending point. If the the sources and sinks are displayed only on a
specific part of the document (line, paragraph, ...) and you need to see
them at the ending point, you first have to click to position the caret
(cursor) in that area, and by doing this you "forget" the location of the
starting point.
Omer Zak asked:
"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?"
My answer is that it should be displayed all the time and on all the
document when the user enables it, and removed when the user disables it.
There is in Windows edit fields a context menu option for "Show Unicode
controls characters". This can give us an idea of a possible user
interface.
Omer Zak asked:
"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)?"
My answer: never display text in logical ordering to end users.
Conclusion (personal opinion): the source/sink markers can be useful, but
they may become too invasive. They are acceptable, and even recommended,
if and only if it is possible to toggle them on and off.
Shalom (Regards), Mati
Bidi Architect
Globalization Center Of Competency - Bidirectional Scripts
IBM Israel
Phone: +972 2 5888802 Fax: +972 2 5870333 Mobile: +972 52
2554160
"Dov Grobgeld" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
26/10/2008 09:20
To
"Omer Zak" <[EMAIL PROTECTED]>
cc
linux-il <[email protected]>
Subject
Re: [YBA] Logical VS Visual Text Selection
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.
--
42 is the answer to everything. Food is the answer to everything except
obesity.
My own blog is at http://www.zak.co.il/tddpirate/
My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
=================================================================
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]
=================================================================
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]
