On Thu, 15 Mar 2001, Mark Davis wrote:
> There are a huge number of problems in the analysis of text that occur with
> visual ordering; these are avoided with logical ordering, which is why we
> ended up using that for Unicode.
I know and agree. As I previously told, I am with Unicode in this. I was
only saying that the current approach of implementors of using only a
logical buffer, a logical cursor, and a visual to logical position
translation table in the case their user clicks in the middle of the text,
is annoying for the general user.
> Even with logical ordering, one can make the editing process work as
> you describe. For example, for character input one can make sure that
> the inserted character appears at the cursor. The key to implementing
> that is to insert the character at a position where it would show up
> at the cursor *after* running through the bidi algorithm. A
> brute-force way to do that is to run the bidi algorithm to get visual
> order, insert the character, then run it backwards to get the logical
> order again, which tells you where to put the character. (This is a
> very rough description -- there are a number of nuances involved, but
> it can be done.)
I have thought of that. There are also some other ways that rely on
the revese bidi algorithm. What I prefer, and am looking forward to find
the time to implement it, is storing also things like embedding levels
with text, which means we can have both logical and visual at hand. And
then trying to have a best guess at when the user wants the character
lgocially inserted when she presses a key, based on the embedding level
and the characters at left and right. It also should have some state,
"entering Indic numbers" or things like that, to help the intelligence.
--roozbeh
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:20 EDT