Re: RTL PUA?

2011/8/21 Peter Constable <petercon_at_microsoft.com>:
> From: unicode-bounce_at_unicode.org [mailto:unicode-bounce_at_unicode.org] 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...
Received on Sun Aug 21 2011 - 13:07:52 CDT