From: Bob_Hallissy@sil.org
Date: Wed Aug 24 2005 - 02:31:10 CDT
On 2005-08-23 22:05:00 Gregg Reynolds wrote:
>Might have been the design intention, but it sure doesn't look like the
>result. By my reading, GSUB is quite capable of reordering glyphs.
>Looks pretty simple to write GSUB stuff using contextual substitution to
>do exactly what you claim can't be done, namely take the character input
>ABC and produce a glyph sequence that look like "ACB". Or "CAB", or
>"ZYZ", or whatever other glyph sequence the font developer desires. Is
>that a misreading?
Consider a simple font that implemented just one GSUB rule:
If you implement GSUB logic to replace ABC with ADE, then the user selects
the E glyph and types a character, what code in the underlying text is
replaced? (Answer: the one corresponding to glyph C)
Using GSUB logic to replace ABC with ACB, then the user selects the B
glyph and types a character, what code in the underlying text is replaced
now? (Answer: Same as above) Is this what should happen if you are trying
to implement reordering? (Answer: No)
It was suggested in another message that cursor handling might get "messed
up" -- indeed this is the crux of the problem. When people claim that
OpenType does not support reordering, it is because of this issue. There
is nothing in OpenType that tracks the logical correspondence between
glyphs on either side of a rule.
For a font technology to support reordering, the font logic has to be able
to instruct the display system what the correspondence between glyphs is.
In my examples above, I've got to be able to instruct the system as to
whether the correspondence is (using some hypothetical notation based on
glyph sequence numbers): (1,2,3) -> (1,2,3) or is it (1,2,3) -> (1,3,2).
OpenType provides no such capability.
Bob
This archive was generated by hypermail 2.1.5 : Wed Aug 24 2005 - 02:29:46 CDT