From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon Feb 11 2008 - 21:41:45 CST
James Kass wrote:
> Making multiple zero-width zero-contour glyphs so that different
> mark classes can essentially be assigned to the same
> *character* strikes me as a beautiful hack.
I don't understand something in your sentence: where are the multiple
zero-width zero-contour glyphs? I can't even find any one (not even CGJ that
is not a glyph and cannot be assigned any glyph, not even an empty one, in
normal mode, i.e. not visible controls mode).
If you speak about characters that are zero-width zero-contours and that can
have multiple mark classes, I can't find any one. CGJ, as a character has a
single combining class (i.e. zero), and there are no other invisible
combining marks (just marks that may become "invisible" by forming ligatures
or by modifying the glyph form of a base character or grapheme cluster such
as viramas/halants).
Your sentence makes little sence for me.
We are speaking about the effect of a single character (CGJ) that is
combining and always invisible by itself (it does not change the base letter
or any combining character encoded before or after it, it just controls
their relative ordering in the final layout, when multiple alternatives
would be otherwise possible and the encoding prefers/dictates the logical
ordering produced by the canonical order. Once the grapheme clusters have
been delimited, then the canonical ordering has been computed to each
grapheme cluster by the renderer, then BiDi ordering applied to the
graphemes, then CGJ dropped, no further reordering is allowed and fonts will
just select the appropriate glyphs in the specified order by transforming
sequences of characters to streams of glyph ids (with some complication for
two-part combining vowels that have parts with different positioning classes
and that require initial transformation), then combining them with GSUB,
mostly using pairs, then positioning them with GPOS or mark-to-mark
positioning.
Most of the preliminary steps that are best handled by the renderer itself,
will not need to be specified in fonts, and this includes all the question
related to the conversion from the logicial ordering to the visual ordering
(there will be a few known exceptions for some combining characters whose
glyph form and positioning class vary according to the base character, and
for which GSUB lookup will be really needed).
This archive was generated by hypermail 2.1.5 : Tue Feb 12 2008 - 09:58:28 CST