From: Erik van der Poel (firstname.lastname@example.org)
Date: Mon Jun 13 2005 - 15:06:27 CDT
>> 4. Obligatory ligatures MUST NOT be broken if the formatting rules
>> introduce no extra space between the affected characters, even
>> if this means some of the characters are rendered in the wrong
>> font or as part of the wrong visual element.
> Perhaps the spec could say that an implementation MAY honor such things
> as a color change (which may not be possible in current font
> technologies such as OpenType?)
It should be possible to implement multi-color obligatory ligatures by
creating 2 or more glyphs for each ligature, possibly with kerning. I
haven't checked to see whether any APIs can kern across runs or change
colors within a run, but that's a separate issue.
>> 5. Combining characters MUST be rendered as the combined grapheme
>> cluster if the system is capable of rendering the combination,
>> even if this means some of the characters are rendered in the
>> wrong font or as part of the wrong visual element. The combined
>> grapheme cluster SHOULD be rendered as part of the base
>> character's element, or, in the case of combining jamos, the
>> initial character's element.
> Here again, shouldn't the style rules trump the Unicode rules?
> Otherwise, why should we even allow tags to be inserted between such
Perhaps tags would be inserted between such characters for reasons other
than style. I.e. some other semantic. So if there is no style change
across the tag(s), the characters should be combined and presented in
the usual way.
If there is a style change across the tag(s) but the implementation
cannot honor it, it's hard to say whether the author considers that
style change (e.g. color) to be more important than the normal
presentation of the character sequence.
We are talking about rather strange cases here, so the implementors
might not get around to implementing them soon even if the specs were
This archive was generated by hypermail 2.1.5 : Mon Jun 13 2005 - 15:07:47 CDT