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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [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 > >
