RE: Unicode editing (RE: Unicode complaints)

From: Roozbeh Pournader (
Date: Mon Mar 19 2001 - 15:20:57 EST

On Mon, 19 Mar 2001, Marco Cimarosti wrote:

> I have been thinking about this the whole week-end, and I too came to
> the conclusion that the resolved embedding levels is what really needs
> to be maintained during editing. Once you have these, you can safely
> throw away all the bidi controls and be sure that you'll be able to
> re-create them when going back to logic order.

Exactly what I was talking about :) I'm not sure about the times two
embeddings occur exactly adjacent to each other. I have a sense that
merging the two may have bad effects.

> One way that comes to mind could be underlining text with *arrows*
> that show the text direction.
> Multiple embedding level would thus be visualized with a downwards stack of
> arrows. All arrows must be shorter that the arrow that precedes it, and
> point in the opposite direction.

That seems great! Anyone who has the time to implement the idea?

> I would say that two separate commands are needed to edit the levels:
> - "Bidi Embed": adds or subtracts *two* to the to the embedding level of the
> selected text.
> - "Bidi Override": adds or subtract *one* to the embedding level of the
> selected text.

... or the text that will follow. Something like the font selection
mechanisms in rich text editors.

> Visual order: abcDEFghiJKLmno
> Bidi Levels: 000111000111000
> Level 0 arrows: -------------->
> Level 1 arrows: <-- <--
> Logic order: abcFEDghiLKJmno

But I like them to appear as:
                           <-- <--
the specific things getting nearer to the specified.

> These are of course very simple examples. The algorithm gets much
> complicated by validity checks, such as ensuring that the user doesn't do
> non-sense embeddings (like LTR text embedded in other LTR text).

..., which may happen when our ser deletes some text. (Or, she may want
the effect; what are these 65 levels for?)

> Moreover, complications certainly arise with cut&paste: I think that the
> levels must be adjusted to avoid non-sense situations.

Also, in a good desktop environment, the clipboard should support this
"text with embedding levels"; that's different from text with bidi

Or, at a second thought, because some applications may be unaware of this
new text type, the application should put bidi controls in the text when
giving in to the clipboard, so good bidi editors can take that and compute
the levels before pasting the text, and bad (!) bidi editors can treat the
text without bothering themselves.


This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:20 EDT