From: Mark Davis (mark.davis@jtcsv.com)
Date: Tue Dec 09 2003 - 11:03:15 EST
I agree strongly. Reordering of glyphs doesn't affect the ability to maintain
styles. Every reasonable package has to retain the mappings back and forth
between character and glyph to maintain styles and to map highlighting/mouse
clicks/etc. The only issue is for combinations. That is, the character => glyph
mappings can be arbitrary combinations of the following:
reordering: easy to retain style
1:1 mapping: easy to retain style
1:n mapping: also easy to retain style
n:1 mapping: this is the place where it gets tricky.
Any time the 1:n mapping is involved, maintaining styles is difficult. For
example, with <sample><red>f</red><green>i</green></sample>, if ligatures are
used for "fi", then you have some choices. (a) disallow the ligature, (b) color
it all one or the other color, (c) if (and that's a big if) your font allows for
the production of an fi ligature with two adjacent 'fitting' pieces, essentially
contextual forms instead of a ligature, then you can do both the ligature and
the color.
Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄
----- Original Message -----
From: "Peter Constable" <petercon@microsoft.com>
To: <unicode@unicode.org>
Sent: Tue, 2003 Dec 09 00:30
Subject: RE: Transcoding Tamil in the presence of markup (was Re: Coloured
diacritics (Was: Transcoding Tamil in the presence of markup))
> From: unicode-bounce@unicode.org 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
>
>
This archive was generated by hypermail 2.1.5 : Tue Dec 09 2003 - 11:50:36 EST