From: Paul Rohr (paul@abisource.com)
Date: Mon Apr 22 2002 - 16:23:34 EDT
At 09:30 PM 4/22/02 +0200, Karl Ove Hufthammer wrote:
>Paul Rohr <paul@abisource.com> wrote in
>news:3.0.5.32.20020422090436.0341acf0@mail.abisource.com:
>
>> How should selections work for combining characters?
>
>See chapter 5.12 of the Unicode book, available online at
><URL: http://www.unicode.org/unicode/uni2book/ch05.pdf >.
Thanks for the excellent reference, Karl.
My question remains, but now the possible answers can be far more precisely
defined. Specifically:
1. Which level of consistent character boundaries Just Works?
--------------------------------------------------------------
In the vocabulary of 5.12 here, the choices are:
- Cluster Boundaries
- Stacked Boundaries
- Atomic Character Boundaries
Since AbiWord is designed to allow easy entry, manipulation, and formatting
of large quantities of text, I'd think we should rule out the third option.
It might make re-entry of portions of a composed character easier, but it
opens up a rat's nest of formatting issues in the UI.
As for the other two, I'm not a native speaker of Devangari, but I'm willing
to guess that cluster selection would be preferred behavior for them. For
example, is it ever meaningful to make *part* of the "ka + vowel sign a"
cluster bold?
OK, now I'll duck while the native speakers set me straight. :-)
2. Which selection mode Just Works for bidi text?
--------------------------------------------------
According to section 3.1.3 of one of Karl's other references:
http://www.w3.org/TR/charmod/#sec-VisualRenderingUnits
there are two possible selection modes for BiDi text:
- logical selection mode
- visual selection mode
As one of the parties responsible for the selection code Tomas inherited,
I'd guess he may have found it easier to implement the logical mode, but I
wasn't paying enough attention when that got implemented.
Is the other mode more desirable? If so, how bad would it be to encapsulate
the necessary selection logic to allow discontiguous selections?
Paul
This archive was generated by hypermail 2.1.4 : Mon Apr 22 2002 - 16:24:27 EDT