Re: Representative glyphs for combining kannada signs

From: James Kass (
Date: Wed Mar 22 2006 - 00:02:07 CST

  • Next message: Philippe Verdy: "Re: FW: Representative glyphs for combining kannada signs"

    Philippe Verdy wrote,

    > But it's up to the "Microsoft Typography" team to verify
    > that it works well in its own Office product for which it is
    > built, and Windows as the target platform that Microsoft
    > also supports. And I think that Microsoft is directly involved
    > itself in the design and verification of the supplementary
    > OpenType shaping feature tables embedded in its licenced
    > font. Personnally, I think that the Microsoft Typography
    > team decision to include partial support (glyphs only) in
    > AUMS for some Indic scripts without the needed OT tables
    > was really bad.


    > Ce cas insoluble survient justement entre les écritures comme Oriya (celles
    > incomplètes, et même erronées, dans AUMS) et l'écriture latine complète:
    > impossible d'avoir les deuxensembles simultanément, sauf en utilisant pour les
    > deux ensembles des "polices géantes Unicode" comme Code2000 (mais à qui il
    > manque trop de ligatures, et dont le design est loin d'être soigné et lisible à
    > l'écran).

    When Oriya was included in pan-Unicode fonts such as Arial
    Unicode MS or Code2000, no Indic-script specific OpenType
    specifications were available, if I'm not mistaken. Since
    specs weren't around, no real display engines for complex Indic
    script text were generally available. Of course, tools for font
    developers to use to insert OpenType tables were both scarce
    and primitive.

    Such fonts were useful for populating Unicode charts and
    not much else. (They still do both.)

    Some developers made Private Use Area schemes for some Indic
    script presentation forms. This was the only way to display
    running Indic Unicode text at that time on our systems. True
    Unicode Indic script text could be converted to-and-from the
    PUA scheme, thus enabling display with the rendering technology
    of that day. (And horrifying the purists.)

    A developer may add a preliminary (or empty) OpenType table
    to an OpenType font to enable generic support for a complex
    script (support from the system which is not font-specific,
    like re-ordering matras).

    If representative glyphs are better than little squares, then
    matras which re-order properly should be an improvement
    over those which don't.

    When support for display of a new script becomes available,
    a developer may be tempted to test that support by adding
    a few display glyphs and preliminary OpenType tables. Under
    the theory that a conjunct which forms is better than one
    which doesn't, the font developer may elect to leave these
    testing glyphs in the release version of the font. After all,
    others may want to do some testing, too.

    Best regards,

    James Kass

    This archive was generated by hypermail 2.1.5 : Wed Mar 22 2006 - 05:19:00 CST