Re: RTL PUA?

2011/8/24 John H. Jenkins <jenkins_at_apple.com>:
>
> John Hudson 於 2011年8月23日 下午9:08 寫道：
>
>> I think you may be right that quite a lot of existing OTL functionality wouldn't be affected by applying BiDi after glyph shaping: logical order and resolved order are often identical in terms of GSUB input. But it is in the cases where they are not identical that there needs to be a clearly defined and standard way to do things on which font developers can rely. [A parallel is canonical combining class ordering and GPOS mark positioning: there are huge numbers of instances, even for quite complicated combinations of base plus multiple marks, in which it really doesn't matter what order the marks are in for the typeform to display correctly; but there are some instances in which you absolutely need to have a particular mark sequence.]
>
> And this is really the key point.  There really isn't anything inherent to OpenType that absolutely *requires* the bidi algorithm be run in character space.  It would theoretically be possible to manage things in a fashion so that it's run afterwards, à la AAT.  But font designers *must* know which way it's being done in practice, and, in practice, all OT engines run the bidi algorithm in character space and not in glyph space.  At this point, trying to arrange things so that it can be done in glyph space instead is a practical impossibility.

One problem of interpretation: I have never suggested that the Bidi
algorithm would need to run in the glyph space. You can still run it
in the character space.

Reread my suggestions where I clearly and explicitly spoke about how
boundaries between runs of characters that are in a resolved direction
and runs of glyphs that are in the same resolved direction just has to
be kept.

The only "borderline" case occuring only if one wants to create some
ligaturing feature (substitution and/or positioning) between glyphs
belonging to distinct successive runs, something that is still for now
unsupported, even though it is visually possible (and may even be
wanted, notably for kerning or microjustification of lines displaying
runs in both directions).

This does not even mean that glyph ids will be reordered for RTL runs
of glyphs or RTL runs of characters. In OpenType, there is clearly the
need in all cases to maintain at least a mapping from positions in the
character streams for each directional run to the positions in the
glyphs stream. But such mapping is evidently not needed for each
character or even for each grapheme cluster, and it does not have to
be bijectively reversible (for example, distinct positions of
directional runs in the characters streams may map to the same
position in the glyphs stream).

And this "surjective"(*) mapping does not even have to be
"monotonic"(*) between each character or grapheme cluster, but only
"strictly monotonic"(*) between non-empty directional runs (otherwise
it would be impossible, in the final drawing step, to compute the
relative positions of runs in the rendered line, because it would be
impossible to sort these non-empty runs along the baseline axis; note
also that empty runs that may occur in the glyphs space can be
skipped, and in fact must be skipped to assert the condition of
"strict" monotony).

Note (*): mathematical meaning of these terms.

For example, most Indic scripts exhibit a *non-monotonic* surjective
function that maps the positions of successive grapheme clusters in
the characters stream, to the positions in the glyphs stream (but
given that Indic scripts are only strong LTR, this is not a
limitation: all streams of Indic characters or streams of Indic glyphs
will never include in their middle any boundary between non-empty runs
with opposite resolved directions).
Received on Wed Aug 24 2011 - 19:09:06 CDT