From: [EMAIL PROTECTED] on behalf of Kenneth Whistler
>> Unicode doesn't prevent styling, of course. But having 'logical' order
>> instead of 'visual' makes it a hard task for the application and the
>> renderer.
>> This is witnessed by the thin-spread support for this.
>
>Yes...
Ken conceded the claim too readily. Glyph re-ordering due to a logical encoding order
that is different from visual order may mean that certain types of styling (of the
re-ordered character) may not be supported in some implementations, but it does *not*
mean that this is, in general, a hard task. Style information is applied to
characters, and as long as there is a 1:m association between characters and glyphs
and there is a path to transform the styling information to match the character/glyph
transformations, styling is in principle possible. (There's a constraint that styling
might not be possible if the styling differences require different fonts but the glyph
transformations that occur require rule contexts to span such a style boundary.)
(Expecting one component from a precomposed character to be styled differently from
the rest, however, would be somewhat hard.)
In particular, for reordering this is easy to demonstrate by considering a
hypothetical complex-script rendering implementation in which processing is divided
into two stages: character re-ordering, and glyph transformation. In the first stage,
all that happens is that a string is mapped to a temporary string used internally
only, in which characters are reordered into visual order. (Surroundrant characters
with no decomposition would be mapped into multiple internal-use-only virtual
characters.) Thus, a styled string such as <string>k<span
color="red">e</span></string> would transform in the first stage to <string><span
color="red">e</span>k</string>. There is nothing hard in such processing.
(Of course, whether it is harder to get people to implement support for one thing
rather than another is an entirely different question.)
Peter Constable
