Mati Allouche wrote:
> [...] All this combines to produce a
> long posting. If this subject is not one of your favorites,
> you should quit before getting bored :-)
And this of course also applies to the follow up.
> In order to ease the reading, I have inserted my answers to
> Marco within
> his own text attached below, tagged with <Mati>... </Mati>.
So, please mind that text beginning with a ">" is not necessarily Mati's
words: parts not enclosed in "<Mati>...</Mati>" is what I wrote in my
original message.
> <Mati>I agree with Marco that, as far as we are defining an
> interface, the order of storing the backing-store is
> immaterial. [...]
> While agreeing that Marco's suggested methodology can be made
> to work, I beg to differ about which one is easier to
> implement. [...]
> Obviously, I cannot do much to convince whoever thinks
> otherwise except to start 2 projects, implementing
> respectively the visual and the logical approach [...]
> Obviously this is not going to happen (too bad, maybe),
> so we will probably stay with our respective beliefs.
Of course. I don't want to push my "belief", also because I am not so sure
that it is correct.
I mentioned this here because, otherwise, my viewpoint could have been
unclear at times. Moreover, regardless how a bidi GUI is actually
implemented internally, I think that *pretending* that you have a
visual-order backing store can sometimes simplify *thinking* about BIDI
behavior.
In other terms, thinking in terms of visual order may help us to understand
the user's "outside" perspective. Then, once a particular issue is clear in
our mind, it is relatively easy to "reverse" the mental idea that we have of
a certain process.
> [...]
> First of all, I would prompt Mati to find a different term
> than "Keyboard Language", e.g. "Keyboard Layout" or
> "Keyboard Locale". [...]
>
> <Mati> I have no doubt that my terminology can be improved. "Keyboard
> layout" is my preference among Marco's suggestions. Maybe
> others want to cast their votes? </Mati>
I hope you won't curse me now... In the meanwhile, Jony Rosenne nearly
convinced me that "keyboard language" is a proper and well-understood term
in the realm of bilingual keyboards...
Maybe you could keep both terms: "keyboard layout" (or "locale", or
"driver") for the fact that you have, say, a Hebrew keyboard installed, and
"keyboard language" (or "mode", or "alphabet") for the fact that your Hebrew
keyboard is currently switched in "English mode" or in "Hebrew mode".
Oh! I feel I'm adding confusion over confusion!
> However, it is not only the terminology that I am proposing
> to erase, but the whole concept of "keyboard language". [...]
>
> <Mati> [...] For instance, a "space" can generally be
> produced from whatever keyboard layout (you see, I am
> amenable to change!) is active.
> Should it be considered as a RTL space or a LTR space? This
> is ambiguous. Considering the context is not helpful if the space is
> inserted between LTR text and RTL text. The keyboard layout is a clue
> about the user's intention which does not require from him an extra
> effort. My opinion is that it would be a waste not to
> exploit it. </Mati>
But there are actually two points here, and I have not been very clear about
which one I was talking about:
1) In every moment, the keyboard is set to a certain "keyboard language"
(however we call it), and you use this information as an additional clue to
determine the directionality of next entered characters.
2) You analyze the directionality (or, as I suggest, the alphabet) of
characters near the cursor, and use this information to set the "keyboard
language".
Number 1 is fine: however the "keyboard language" has been switched
(manually or automatically) it is a good clue for determining the default
directionality of incoming neutral characters.
What I meant is that your document has a lot of complicated rules, scattered
all over, to implement number 2, and I feel that *this* point:
a) Complicates too much your Guidelines, without delivering a big added
value because:
b) Such a thing is not necessarily needed by the user (they may prefer
manual switching) and, anyway:
c) Directionality alone is not enough to implement this function well. If
(and I doubt) users need this automatism, it is much easier and powerful to
look in which *script* the text around the cursor is written.
So what I wanted to say is:
I) In any case, remove all these rules (to implement point 2) from *this*
Guidelines, because it is very complicated for implementers, and it's not so
clear whether users need it.
II) If it is proven that users welcome such a function, make it a different
specification (totally disconnected with BIDI issues) and base it on
*scripts*. In this way, it will also work with, say, English/Thai keyboards,
or Arabic/Hebrew keyboards.
> ** Remove "Cursor Level"? (sections 3, 9, and elsewhere)
> [...]
>
> <Mati> Considering that Unicode allows up to 63 levels of
> embedding, the
> cursor level is the only way I know to formalize the various
> situations
> occurring at boundaries between text runs of different
> levels, considering
> that the difference can be greater than 1. </Mati>
I have seen no evidence in your guidelines that this is "the only way" to do
this.
On the contrary, I would rather talk about a "key level". Each alphabetic
key has associated a static bidi level, which is either 0 (for LTR
characters) or 1 (for RTL characters).
For neutral characters there can be two approaches:
- Static: they have the level which is predominant in that keyboard. (E.g.,
space and punctuation will be level 0 on an Italian keyboard, and level 1 on
a Hebrew keyboard).
- Dynamic: their level (0 or 1) is determined on-the-fly with the techniques
that we were talking about above (same oddity as the surrounding text; same
as Static if the surrounding text is ambiguous).
After the character is inserted, these levels 0 or 1 are raised to a level
suitable to the text surrounding the cursor. Examples of rules to do this:
1) If the two characters around the cursor both have the same parity as the
inserted character, the level of the inserted character is set to, say, the
lowest of the two. (E.g., you text was "22|44"; after insertion it is
"220|44": change it to "222|44". The "simple case" is a special case of
this: you text was "00|00"; after insertion it is "000|00": leave it as it
is).
2) If the two characters around the cursor both have a parity different from
the inserted character, the level of the inserted character is set to one
more of the lowest of the two. (E.g., you text was "22|44"; after insertion
it is "221|44": change it to "22|344").
3) If the two characters around the cursor both different parity between,
the level of the inserted character is set to the same value as the one
which has the same parity as the new character. (E.g., you text was "22|33";
after insertion it is "220|33": change it to "222|33").
In all cases, the cursor itself does not need to have a level: it is just a
"position".
> Why is it needed to put in place all this heuristics to anticipate the
> directionality of the next entered character?
>
> <Mati> Because one important objective of the guidelines is to let the
> text cursor predict, as accurately as possible, where the
> next character is going to be inserted. You cannot do that without
> some sophisticated heuristics. </Mati>
OK. But it is useless to calculate this position in *advance*. Why not
waiting for the next character to be typed, so that you can use the extra
clue constituted by the new char's directionality?
BTW, in a recent discussion on the Unicode list, we talked about
implementing similar heuristics in a "visual order" implementation.
Keeping in mind the basic principle that, in visual order, a typed character
normally goes exactly where the cursor is, these heuristics have been
described as an "automatic movement" to a more handy position.
(I realize that I might have been clumsy here, but I prefer to avoid
repeating a lengthy and boring discussion that was done just a few time
ago).
> You can simply wait for the character to be entered and then
> decide how to handle it.
> <Mati> and if the result is not what the user expected, he
> will have to erase and retype. Ichhhsss! </Mati>
Well, should I reverse your assertion? And if your "cursor level" fails to
match the user expectation? She will have to erase and retype. Ichhhsss!
The fact is that heuristics would not be called "heuristics" if they
succeeded in all cases.
Whatever the approach, the goal here is meeting the user expectations *most*
of the time; meeting them *always* is just a lost battle.
> ** Remove "Arabic Ligatures"? (section 23)
>
> <Mati> [...]
> Whether fonts are monospace is not relevant, IMHO. [...]
> </Mati>
Right. My point was another: there are applications (e.g. "text mode"
command lines) that must display the cursor on one *cell*. If laam-alif is a
single cell, they have no way of selecting half a cell.
> <Mati> Guilty: this is not a purely Bidi issue. Still it happens in a
> Bidi script, so I address it. [...]</Mati>
Apart the comment about cell-oriented devices, my comment was excessively
critical.
Even if you cannot and wish not to deal in detail with all the complex issue
of ligatures, you are right in adding a small implementation note to help a
newcomer.
> ** Remove "Programming Editors"? (section 25)
>
> <Mati> Since much of the foundations are common with other
> applications, I have cut my work and made one document. </Mati>
OK. As said, this part is so interesting that it would deserve a Guideline
on its own, of course, referencing the "main" Guidelines for general BIDI
issues.
> ** Add sections about joining and splitting lines?
>
> [...]
> 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).
>
> <Mati> I think that here Marco is proving my theory, that logical
> backing-store is easier to implement. On logical data, splitting or
> joining lines have exactly the same effect as on pure LTR data. After
> doing whatever is done, you only have to rerun the Bidi
> algorithm on the result to present the updated situation. </Mati>
Why do you think that I am proving one your theory!?
Whatever the approach, there is absolutely nothing complicated here.
The question is another: should the new paragraph containing "english" in
the example be LTR or RTL.
You say that you would re-run the UBA on it so, implicitly, you say that it
should be LTR. This is fine, as it only contains LTR characters.
But I say that it should be RTL. And this is fine too, because it originally
was a piece of a RTL line so, probably, it is a segment of RTL text
containing a RTL quotation...
Both opinions are trivial to implement in both logical or visual order.
The problem here is that both are fine and correct, and both could meet the
user expectations in some cases and miss them in other cases.
The matter is like driving on the left of right part of the road: both are
fine, as far as all drivers on my road use the same conventions.
So, what I am suggesting is that you add a note to make implementers *aware*
of this option, and prompt them to make an early choice, possibly coherent
with their environment (e.g. what is usually done on the target operating
system, etc).
> <Mati> It does not matter if the application does word
> wrapping or line
> boundaries are manually set by the user. What matters is
> that some lines
> are too long to be displayed in the presentation area. This is a very
> real problem in a Bidi context, and it is a can of worms that
> I hoped to
> leave unturned, because I am not sure what is the best
> solution. /Mati>
I understand your point, and agree that it is indeed a can of worms.
However, lines too long for the presentation area should not be seen as a
limit case: unfortunately this is a normal situation, and *all* application
displaying text should be able to address it, somehow.
It doesn't make much sense to hide the problem and let implementers discover
it just the day before the expected delivery...
> [...]
> It should be considered whether, in a bidi environment, style
> sheets etc. should specify alignment in an absolute manner
> [...]
> <Mati> In the context of a User Interface, I think that absolute
> directives are preferable (need less thinking before
> choosing). The style
> (absolute versus relative versus both) used in a markup
> language are not
> in the scope of my document. </Mati>
You are right. My comments here did not apply to your document. I was rather
thinking aloud about a contradiction that I see in current word processors
and mark-up languages.
> ** Add sections about bidi levels > 2 and/or copy and paste?
> [...]
> BTW, this is the kind of problems that could perhaps be simplified by
> having a visual-order backing store and a visual-order clipboard.
Copy and paste vs. bidi levels... This is another ugly can of worms.
And I am not so sure anymore that visual order really simplifies it: it does
indeed simplifies some aspects, but, probably, specularly complicates other
things.
I either case, starting coding before having carefully designed this aspect
can lead to very bad surprises, methinks.
I think that, if you manage to add at least a general discussion about this,
your Guidelines really start looking like solid rock!
Ciao.
_ Marco
This archive was generated by hypermail 2.1.2 : Fri Jul 06 2001 - 00:18:17 EDT