Re: 28th IUC paper - Tamil Unicode New

From: John Hudson (tiro@tiro.com)
Date: Tue Aug 23 2005 - 15:39:29 CDT

  • Next message: Gregg Reynolds: "Re: Windows Glyph Handling"

    Antoine Leca wrote:

    > One problem inherent of the OpenType idea of dealing with Indic scripts is
    > that the job to reordering the _glyphs_ is under control of the
    > "application" (i.e. the rendering engine, Uniscribe and its concurrents),
    > without knowledge nor information from part of the font other than the
    > mapping from Unicode codepoints to glyphs. OTOH the encoding can control
    > part of the process through use of the joiners.

    While this description is accurate, I'll point out the ways in which this is not a
    'problem', but a sensible trade-off.

    > First, this creates a pretty heavy workload onto the engine, to deal with
    > the corner case, particularly for the scripts (like Tamil) which reorder the
    > left-standing matras to the left of the base consonant, while the process is
    > thought toward helping formation of maximally ligatured conjuncts.

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

    Further, the OpenType lookup model is relatively slow in terms of processing time,
    compared to the state table/engine model used in AAT and Graphite. Character level
    handling of things like re-ordering, string analysis, canonical composition/decomposition
    is very much faster than using OpenType GSUB lookups.

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

    I agree with the remainder of your letter, especially your point about OpenType for Indic
    scripts being an emerging standard.

    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 - 15:40:21 CDT