From: [email protected] [mailto:[email protected]] On Behalf Of Philippe Verdy

>> 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". 

That statement isn't adequate: the results of re-ordering may result in 
contexts in which ligatures will occur. That can happen, for instance, in 
displaying Indic scripts.


> 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.

I'm not sure what it means to create a ligature of glyphs in arbitrary order. 
If you mean a rule to substitute [g1 g2] with [g3] won't apply if the sequence 
processed by the OpenType Layout lookup processor is [g2 g1], then that's true: 
if the behaviour of the script is such that glyph re-ordering is appropriate, 
then a rendering engine for OpenType should do that reordering, and 
substitution lookups in OpenType fonts should be written to assume that that 
reordering has taken place.


>>> 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. 

Um... Why not? If the mirroring isn't in reflected in 
http://www.unicode.org/Public/5.1.0/ucd/BidiMirroring.txt, then it must be 
handled by glyph substitution in the font as a normal GSUB operation.



Peter


Reply via email to