From: John Hudson (tiro@tiro.com)
Date: Tue Aug 23 2005 - 19:42:30 CDT
Richard Wordingham wrote:
>> I mean OpenType. The OpenType GSUB and GPOS lookup types are not
>> designed for glyph *re-ordering*. There is no mechanism within
>> OpenType to say 'take this sequence ABC and rearrange it to ACB'.
> I quote from the Context Substitution Format 1 subsection of
> ....open_type\Typography\otspec\gsub.htm:
> 'For example, if a client is to replace the glyph string <abc> with its
> reverse glyph string <cba>, the input context is defined as the glyph
> sequence, <abc>, and the lookups defined for the context are (1) "a" to
> "c" and (2) "c" to "a". When a client encounters the context <abc>, the
> lookups are performed in the order stored. First, "c" is substituted for
> "a" resulting in <cbc>. Second, "a" is substituted for the "c" that has
> not yet been touched, resulting in <cba>. '
This section of the OT spec is intended to provide an example of how lookup ordering is
applied, not as a recommendation for using GSUB to perform language shaping through glyph
reordering, which is what we have been talking about in this thread and that which
preceded it.
As I exlained in a previous messages, yes it is possible to perform a series of contextual
substitutions to do some reordering at the glyph level, but that is not the same thing as
having e.g. the state table mechanism of AAT and Graphite that is specifically designed to
be able to perform reordering as required for language processing. There is a big
difference between being able to perform clunky multi-stage GSUB lookups to do something
and having a mechanism that is designed to do that thing. And there is a difference
between an architecture that accidentally enables a thing and an architecture in which
that thing is expected or required.
Whatever the ability of OpenType lookups in this area, the fact remains that neither
Microsoft nor Adobe believes that common language shaping tasks belong in fonts and
designed OpenType with the intent that such tasks should be done by an external engine.
You may find that particular language shaping tasks *could* be performed in OTL table
lookups, but you shouldn't be surprised if you also find that some cannot, because the
format was not designed to be able to guarantee support for such tasks at the font level.
Here's an illuminating case. In some fonts I use OTL <smcp> feature lookups to perform a
multi-stage* lowercase-to-smallcaps substitution for the German ß (eszett). I do this
because I found that different applications performed or failed to perform case mapping
for the eszett in different ways, and because I wanted the <smcp> feature to handle the
mapping independently of character casing and the <c2sc> feature. Since the Adobe apps I
was using didn't seem to handle eszett casing, and hence smallcap mapping via <c2sc>
correctly, I asked Adobe why they didn't consider doing the same thing in their own fonts,
especially since it would not interfere with a casing+<c2sc> approach if that were added
to the apps later. They told me that even this was considered common language processing
by them and that it did not belong in fonts. That gives you some idea of the basic
centrality of this philosophy to the OpenType model.
John Hudson
* I use a multi-stage approach because some application support one-to-many substitutions
and some do not, so I map /germandbls/ to the single glyph /germandbls.small/ (for the
benefit of apps that can't handle one-to-many substitutions) and then map that to the
two-glyph sequence /S.small/S.small/ (for the benefit of apps that can, so that the glyphs
can be independently letterspaced if desired).
-- Tiro Typeworks www.tiro.com Vancouver, BC tiro@tiro.com
This archive was generated by hypermail 2.1.5 : Tue Aug 23 2005 - 19:44:00 CDT