Re: Windows Glyph Handling

From: Gregg Reynolds (unicode@arabink.com)
Date: Tue Aug 23 2005 - 16:05:00 CDT

  • Next message: Adam Twardoch: "Re: Windows Glyph Handling"

    John Hudson wrote:
    > Richard Wordingham wrote:
    >
    >>> In the OpenType model re-ordering is specifically NOT handled at the
    >>> glyph level, but at the character level. This is why it only works
    >>> with standard Unicode characters, and not codepoints in what I've
    >>> come to regard as the 'Pretty Useless Area'.
    >
    >
    >> Do you mean 'OpenType' or something like 'Uniscribe/OpenType' or
    >> 'Microsoft'?
    >
    >
    > 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'. It is a
    > presumption of the format that re-ordering, and other aspects of
    > language processing, is done at the (buffered) character level. Both
    > Microsoft and Adobe will tell you this. It was a design decision, and
    > one that has been discussed in numerous articles, discussion lists,
    > conference sessions etc. for the better part of a decade.

    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? To me it looks like that kind of stuff has nothing
    to do with language processing; it's purely formal. That's what makes
    OT attractive - language typesetting knowledge can migrate from
    application code to the font.

    The unfortunate fact is that apparently nobody fully implements GSUB
    capabilities, with the possible exception of some Adobe products.

    >
    >> There's no mention of re-ordering by Uniscribe (or equivalent) or of
    >> breaking into runs by script - Step 0!. You have to read higher level
    >> documentation to realise that the characters may be re-ordered (or
    >> even changed!) before the font tables can affect them.
    >
    >
    > Yes, precisely. Character level re-ordering is not discussed within the
    > OpenType spec itself because it is not something that happens within the
    > font format. The OT spec also doesn't talk about the need for character
    > level analysis of e.g. Arabic text to determine which OTL features
    > should be applied to the default glyphs for each character dependent on
    > word position and neighbouring characters, because that is not something
    > that happens within the font format.

    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. 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.

    > OpenType fonts are part of larger
    > architectures for script and language support, always relying on
    > external shaping engines for a variety of functions, whether those
    > shaping engines are in Unscribe, ICU, CoolType, etc. The shaping engines
    > handle the character end and the font handles the glyph end; between
    > them is some kind of generic OTL handler such as Microsoft's OTLS.

    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.

    -gregg



    This archive was generated by hypermail 2.1.5 : Tue Aug 23 2005 - 16:06:17 CDT