From: Mark Davis (email@example.com)
Date: Mon Jun 13 2005 - 16:44:26 CDT
It is always possible to replace a ligature by a sequence of shapes which,
when put together, form the ligature shape. These then can each have the
style of the corresponding original character. However, this does depend on
the rendering system placing the glyphs exactly adjacent to one another so
that the result is reasonable. (In earlier lives I remember that we created
Arabic shaping forms to slightly overlap, so that if there were variances in
positioning it would not leave a gap.)
However, whether it is worthwhile for the average font designer to go to the
(perhaps considerable) extra trouble to do this is questionable, so the
rendering system always needs to be prepared to deal with real ligatures;
and applying a uniform style to them based on some combination of the styles
of the component characters is a perfectly reasonable approach.
----- Original Message -----
From: "Erik van der Poel" <firstname.lastname@example.org>
To: "fantasai" <email@example.com>
Cc: "Unicode Mailing List" <firstname.lastname@example.org>; <email@example.com>
Sent: Monday, June 13, 2005 13:06
Subject: Re: Arabic letters separated by markup
> >> 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
> > characters?
> 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 - 16:46:05 CDT