Re: Windows Glyph Handling

From: John Hudson (tiro@tiro.com)
Date: Tue Aug 23 2005 - 19:42:30 CDT

  • Next message: Philippe Verdy: "Re: Questions re ISO-639-1,2,3"

    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