2011/8/21 Peter Constable <[email protected]>: > From: [email protected] [mailto:[email protected]] On > Behalf Of Philippe Verdy > >> Hmmm.... Given the current standard in OpenType, and the fact that >> OpenType fonts cannot reorder glyphs to support the BiDi algorithm >> and correctly handle featues like ligatures... > > I agree that OpenType font tables cannot to glyph re-ordering. But totally > incorrect in saying that it cannot handle ligatures.
I meant "recognizing and generating ligatures in the context where re-ordering has been performed externally by the renderer". Ligatures can only be recognized in OpenType, provided that the layout engine has performed the reordering itself, because OpenType fonts won't recognize ligatures with glyphs in arbitrary order or intersperced with other unrelated characters coming from an unreordered glyph sequence. >> What this means is that, in practice, PUA are only usable in fonts for >> characters with strong LTR directionality, excluding all reordering and >> mirroring. > > In the OpenType specification, the only data related to glyph mirroring that > a rendering engine is assumed to have is the bidi mirroring data from TUS > 5.1. (See http://www.microsoft.com/typography/otspec/TTOCHAP1.htm#ltrrtl.) > All other glyph mirroring is to be handled using glyph substitution data in > OpenType Layout tables in fonts. Exactly, but mirroring data for remapping glyphs will not be be part of that font. Glyph mirroring substitution data in substitution rules of OpenType fonts does not work because it cannot solve the ambiguity of the expected direction, as the context length is limited (otherwise the number of contextual pairs to recognize would explode combinatorially, making such implementation unpractical to implement in decent table sizes in fonts, even if we use class-based substitution, because the necessary character-to-class mappings would also require large mapping tables, including for a lot of characters that are not even mapped in the font and for which the font was never designed). Mirroring behavior is then best handled in the layout engine, which has a more global and centralized view of properties of the whole UCS. Here, we just want to complement this view of character properties, by permitting to specify a set of character properties for PUA characters only, expecting that the layout engine will handle all the other character properties for non-PUA characters, using the standard data of the UCD...
