Re: 28th IUC paper - Tamil Unicode New

From: John H. Jenkins (
Date: Tue Aug 23 2005 - 17:08:48 CDT

  • Next message: John H. Jenkins: "Re: 28th IUC paper - Tamil Unicode New"

    On Aug 23, 2005, at 2:39 PM, John Hudson wrote:

    > The converse would be a very heavy workload for the font and for
    > font developers. This is the approach taken by AAT and Graphite
    > (although the latter at least has the benefit of a relatively
    > simple development language), and one only has to compare the
    > quantity of OpenType fonts in existence to the quantity of AAT or
    > Graphite fonts to understand why the OpenType approach might be
    > considered a reasonable one.

    Well, that's not a fair metric since OT layout is supported on the
    platform with the overwhelming majority of the market share.

    Not that the OT approach is unreasonable. I really wish there were a
    hybrid approach available, where one can rely on the shaping
    knowledge in Uniscribe (or its equivalent) but still have the ability
    to provide extensive, font-specific features.

    > Part of the reason for the relative market success of OpenType
    > compared to AAT or Graphite is of course due to the fact that it is
    > supported in several very major applications. But you shouldn't
    > underestimate the degree to which the difficulty of AAT development
    > has been a problem for more than a decade now.

    To say the least. :-( One wishes Apple had allocated the resources
    back in the GX days when we were relatively flush to make it easy to
    make AAT fonts. (The reason why the original AAT metamorphosis table
    is called a 'mort' table is because it just about killed you to make

    > Most font producers are software developers only in the most basic
    > sense of the word: they are designers, not programmers, used to
    > working with visual drawing tools not state tables. Microsoft and
    > Adobe very sensibly realised that they couldn't expect font
    > developers to be responsible for the heavy lifting of language and
    > script support.

    This is a valid point with which I'd agree.

    >> Then, it put the whole idea at the mercy of the correctness of the
    >> initial
    >> analysis of the engine writers.
    > Yes, although it is easier to fix a bug in one shaping engine than
    > it is to fix a bug in hundreds of fonts.

    This is definitely true.

    John H. Jenkins

    This archive was generated by hypermail 2.1.5 : Tue Aug 23 2005 - 17:09:42 CDT