From: John Hudson (tiro@tiro.com)
Date: Tue Aug 23 2005 - 17:18:14 CDT
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?
I said that there is no mechanism within OpenType to say 'take this sequence ABC and
rearrange it to ACB', whereas there is such a mechanism in AAT and Graphite. Sure you can
perform some elaborate multi-stage contextual lookups in an OT font to produce something
that looks like ACB, but this would be slow to process and dependent on the application
supporting all the lookup types involved (not currently a reliable assumption). And I'm
not sure that all the kinds of character re-ordering required for Indic-derived scripts
could be managed in this way, even if it were desirable. It is a heck of a lot simpler nd
faster to re-order the default glyphs prior to OTL processing by re-ordering the
characters, which is why the designers of the OpenType spec decided that this is how it
should be done.
> To me it looks like that kind of stuff has nothing
> to do with language processing; it's purely formal.
The kind of re-ordering we've been discussing is specifically language processing related:
in the case of Indic scripts it is basic to the ISCII and Unicode model, which requires
that re-ordering takes place in order to correctly display the phonetically ordered text.
> The unfortunate fact is that apparently nobody fully implements GSUB
> capabilities, with the possible exception of some Adobe products.
Actually, Adobe is the company that currently fails to fully implement GSUB capabilities,
because none of their apps support one-to-many substitutions (GSUB lookup type 2).
Microsoft supports all lookup types.
If you are talking about support for GSUB related OTL features, then no one supports all
the registered features.
> Are you mistaking implementation for design? It seems like it would be
> a fairly simple matter to write purely formal GSUB stuff that will shape
> Arabic characters properly using contextual substitution.
Yes it is possible, and I have seen one font that does this. My point was that this aspect
of language processing *like the Indic reordering* is not expected to be part of a font in
the OpenType model as designed *and* as implemented by both Microsoft and Adobe.
> You just have
> to look at three characters at a time. The fact that most
> implementations don't support contextual substitution fully doesn't
> imply there is some sort of requirement that client software must
> understand Arabic contextual substitution.
But if you ask anyone at Microsoft and Adobe, they will tell you that this is the
expectation, because separation of common language shaping from glyph processing is one of
the key design philosophies of OpenType. This has been stated so many times in so many
places, beginning with the OT Jamboree at Microsoft way back in 1998, that I'm surprised
we're having this conversation.
> Not a requirement, only one possible implementation design. Arabic
> shaping logic can be encoded entirely in open type tables, as far as I
> can see.
You are totally missing the point. Yes, as it happens *Arabic* shaping logic can be
handled entirely within the OT tables (although inefficiently in terms of processing
time). But this is an accident, as seen by the fact that this is not true of shaping for
*all scripts*, which are expected and required to be handled in conjunction with a shaping
engine.
John Hudson
-- Tiro Typeworks www.tiro.com Vancouver, BC tiro@tiro.com
This archive was generated by hypermail 2.1.5 : Tue Aug 23 2005 - 17:19:27 CDT