> Matitiahu Allouche (Mati) has prepared a document "Guidelines
> of a Logical User Interface for Editing Bidirectional Text".
> It is being discussed at the SII.
>
> With his kind permission, I have placed it at
> http://www.qsm.co.il/Hebrew/logicUI22.htm
Thanks for the link! Matitiahu's document is a excellent summary of the kind
of problems that have been discussed recently on the Unicode List, and a
source of sensible solutions to these problems.
> Comments are welcome.
<DISCLAIMER>
I have to warn everybody that I have no working knowledge of bidirectional
editing, so my comments should not be taken too seriously.
Moreover, my judgment is quite influenced by having a rather different
approach to bidirectional editing than Matitiahu: I would use a
*visual*-order backing store, rather than a logical-order one. For those who
haven't followed the discussion about this on the Unicode List, these are
the main points of this approach:
1) The Unicode Bidi Algorithm is run only *once* on each paragraph.
It doesn't matter when this is done, and whether it is done on the whole
document or only on some parts of it; the only important thing is that the
UBA is run on a certain paragraph *before* any editing operation is done on
that paragraph.
2) An "Inverse Unicode Bidi Algorithm" (shall I call it "IUBA"?)
must be run on each paragraph that has undergone point 1. This has to be
done (a) before saving the document being edited and (b) before delivering
pieces of text to algorithms that assume logical order (e.g., search
functions or spellcheckers). The definition of this "reverse bidi" is one of
the potential weak point of this approach. However, it must be noted that
IBM's ICU library already contains an implementation of such an algorithm by
Markus W. Scherer, and that this implementation is surprisingly similar to a
"straight" UBA.
3) After point 1 and since point 2, the backing store is in visual
order, and all editing operations are relatively similar to editing in a
single directionality.
IMHO, this approach simplifies most of the editing actions that Mati calls
"visual functions". But, on the other hand, it also makes slightly more
complicated the actions that Mati calls "logical functions"...
However, regardless of the different approach taken as to the internal
method, the external working of this "visual" approach should be very
similar to what Mati described. So, here are my comments:
</DISCLAIMER>
Firstly, there are some concepts in Mati's document that, IMHO, add
complexity without delivering much usefulness. So my suggestion is to remove
them, or to expand them to separate guidelines.
Then, there are a couple of issues that, IMHO, are not dealt with in the
necessary detail.
** Remove "Keyboard Language"? (sections 3, 4.a to 4.d, 9, 21, and
elsewhere)
**
First of all, I would prompt Mati to find a different term than "Keyboard
Language", e.g. "Keyboard Layout" or "Keyboard Locale". It sounds funny that
one should go in "English mode" to type in Italian (or "Hebrew mode" to type
in Yiddish, or "Arabic mode" to type in Persian, etc.).
However, it is not only the terminology that I am proposing to erase, but
the whole concept of "keyboard language". I feel that it adds a lot of
complexity to the Guidelines but, on the other hand, it delivers very little
usefulness.
Consider: the choice of keyboard language (or alphabet) depends only on the
language's default directionality, so how can this be useful in the case of
languages (or alphabets) that have the same directionality?
Users who know pairs of languages with opposite directionality (e.g.
Hebrew/Russian, or Arabic/English) will have access to this feature, while
users who know pairs of languages with the *same* directionality (e.g.
English/Russian or Hebrew/Arabic) won't have it. What's the point?
A more useful way to implement such a feature is looking at the actual
*scripts* present in the document, rather than at their directionality. This
could be done by using the ranges specified in
<http://www.unicode.org/Public/UNIDATA/Scripts.txt>.
But, then, all this has nothing to do with bidirectionality, so why not
isolating the whole issue and making it the subject of another Guideline
document?
** Remove "Cursor Level"? (sections 3, 9, and elsewhere)
**
This is another complex feature of the Guidelines of which I don't see of a
great usefulness.
Why is it needed to put in place all this heuristics to anticipate the
directionality of the next entered character?
You can simply wait for the character to be entered and then decide how to
handle it.
In the meanwhile, the cursor could stay wherever it was at the end of the
last entry or cursor move.
** Remove "Arabic Ligatures"? (section 23)
**
The solution proposed for laam-alif is a very sensible compromise, and I
agree that it will be OK for most applications.
However, the issue of ligatures may be much more complex in some kinds of
applications (e.g. desktop publishers) while, on the other hand, it may be
handled in a much easier way on some other kinds of applications (e.g.
monospaced command lines).
Moreover, also this issue has nothing to do with bidirectionality. On the
contrary, the most complex ligatures are found in perfectly RTL scripts such
as the alphabets of India or South-East Asia.
So, I'd suggest to remove the whole section, or to reduce it to a small note
when dealing with cursor movement.
** Remove "Programming Editors"? (section 25)
**
Don't misunderstand me: this is one of the most valuable sections of the
whole Guidelines. This section clearly shows Mati's great experience with
programming in RTL languages, and it would have been worth reading the whole
Guidelines only for this.
For this reason, wouldn't it perhaps be the case of turning this section
into a separate guidelines document about bidi editing for programming
languages, scripting files, etc.?
** Add sections about joining and splitting lines?
**
The Guidelines mentions nothing about how a line (or paragraph) can be
split, or how two consecutive lines (or paragraphs) can be joined.
I don't mean the precise commands to be used (many applications use Enter,
Delete and BackSpace to do this, while other applications have ad-hoc
commands like control-J and control-S), but rather the effects that these
commands should have.
For instance, when two lines are joined, what should be the directionality
of the resulting line? Some options are: same as the first line; same as the
second line; same as an hypothetical document (or system) directionality;
recalculated according to the UBA.
Similarly when a line is split. Imagine that my line is RTL and it contains
"HEBREW|english" (in logical order), and that I split it where the cursor
("|") is, what should be the directionality of the line containing
"|english"? Options are that it should be RTL (because it was a piece of a
RTL line), or that it should be LTR (because it only contains LTR text).
** Add sections about alignment?
**
The Guidelines do not specify on which side the text should be aligned.
In plain text, it is quite intuitive that LTR lines should be left-aligned,
while RTL lines should be right-aligned.
This seemingly simple rule, however, becomes complex when there are lines
too long to fit in the editing windows.
Applications that do word-wrapping should be prepared to segment the display
buffer starting from either the left or the right side of the buffer,
depending on each line's base direction.
Applications that allow scrolling the text horizontally, should be prepared
to scroll on either side of the window. Moreover, they might require some
means (different background colors, etc.) to show that some areas in the
window are actually "inexistent space" *before* the start of a line.
E.g., if a file contains a long LTR line ("a very long danish line") and a
long RTL line ("A VERY LONG HEBREW LINE"), you may see the following display
(where "[" and "]" represent the edges of the window):
[a very long dan]
[BEH GNOL YREV A]
If you want to move the cursor on the LTR line, in order to read the whole
word "danish", you can obtain this display (where "#" represent "inexistent
space"):
[ery long danish]
[ GNOL YREV A###]
Similarly if you want to see the whole word "HEBREW":
[###a very long ]
[WERBEH GNOL YRE]
So far so bad with plain text. Applications doing rich text have the
additional complication of explicit text alignments which is independent
and, perhaps, in contradiction with the natural alignment determined by the
base direction.
It should be considered whether, in a bidi environment, style sheets etc.
should specify alignment in an absolute manner (left-aligned vs.
right-aligned, etc.), or in a relative manner (start-of-line-aligned vs.
end-of-line-aligned), or both.
** Add sections about bidi levels > 2 and/or copy and paste?
**
The Guidelines don't take in much consideration Unicode's explicit embedding
and overrides controls, and the consequent bidi levels 3 to 63.
These higher levels are mentioned, but the main goal is clearly editing with
levels 0 to 2 (also known as "implicit bidi").
It should be specified what the application is or is not allowed to do with
these controls. Can the cursor stop on one of them? Can they be deleted?
The most complicated part with bidi controls is, IMHO, related to clipboard
operations. Imagine that I have a line containing (in logical order):
this is english text containing <rtl>HEBREW TEXT CONTAINING
<ltr>russian text containing ARABIC TEXT<pdf> in it<pdf> IN IT<pdf> in it
In visual order, this should become something like:
this is english text containing TI NI russian text containing TXET
CIBARA in it NGININATNOC TXET WERBEH in it
Imagine that I start a visual selection from "russian" on the left to
"NGININATNOC" on the right. If I copy this, what would be put in the
clipboard?
Some options are (logical order):
1) CONTAINING russian text containing ARABIC TEXT in it
2) CONTAINING <ltr>russian text containing ARABIC TEXT<pdf> in it
3) <rtl>CONTAINING <ltr>russian text containing ARABIC TEXT<pdf> in
it<pdf>
The matter has to be considered because the 3 lines would re-display very
differently when, e.g., pasted on an empty line:
1) in it TXET CIBARA russian text containing NGININATNOC
2) in it russian text containing TXET CIBARA NGININATNOC
3) russian text containing TXET CIBARA in it NGININATNOC
BTW, this is the kind of problems that could perhaps be simplified by having
a visual-order backing store and a visual-order clipboard.
**
**
And that's all, I think.
I hope you won't think that I am too critic or fastidious. Rather, I think
that Matitiahu's document is a really good work, so I though that, within my
limits, it was worth spending some time to find any possible way to make it
more solid.
_ Marco
This archive was generated by hypermail 2.1.2 : Fri Jul 06 2001 - 00:17:16 EDT