From: Gregg Reynolds (firstname.lastname@example.org)
Date: Wed Aug 24 2005 - 10:20:22 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)
My answer is: it depends. This is not an issue for OpenType, in my
opinion, but for the implementation of an OT service, whether that
implementation is located in an application or in some kind of
It's true that a font with contextual substitution rules imposes a
burden on (application) clients to manage context at some level, but it
looks to me like that should be reducible to "manage n characters at a
> 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.
I'm not sure there should be. OT is not a spec for a management
service; it's just data.
Anyway, it's clearly incorrect to say that *Open Type* does not support
glyph reordering - it does, obviously. But it is not a service. By
analogy, SQL supports joins, whether a particular implementation chooses
to support them or not. One might say that OpenType glyph reordering
semantics are not *sufficient* to manage all display/selection issues
involved in text handling, but I don't think that's true either. It all
depends on how far an implementation wants to go. Seems to me it should
be possible to write an OT service provider that could handle all that
stuff for a client app based solely on the info (policies) in OT tables.
> 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.
Hmmm, I see what you mean, but I don't think that's an issue for the
Open Type spec. Informing the client of *anything* is beyond the scope
of OT - it's just a set of tables and rules for looking things up. I
don't see any reason an OpenType engine could not provide the info you
note above - all the info is there.
This archive was generated by hypermail 2.1.5 : Wed Aug 24 2005 - 10:21:49 CDT