2011/8/24 John H. Jenkins <jenk...@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).