Re: DIY OpenType Re-ordering (was: Representative glyphs for combining kannada signs)

From: Vinod Kumar (
Date: Thu Mar 23 2006 - 04:48:05 CST

  • Next message: Mark Davis: "Re: OT and combining diacritics (was Re: Representative glyphs for combining kannada signs)"

    On 3/23/06, Peter Constable <> wrote:

    > > Behalf Of Vinod Kumar
    > > Reordering of glyphs within the font becomes necessary when the font
    > > does not have some glyphs.
    > Not so. The Indic shaping engine in Uniscribe has been updated to
    > accommodate variations in re-ordering based on the nature of the glyph
    > substitutions in the font. The recommendations for Indic OpenType font
    > implementations is in process of being updated to reflect the changes.
    If Uniscribe chooses to implement a shaping pipeline with back and forth
    interaction between the stages (char level reordering <-> font ),
    multi pass substitutions with the OpenType font using myriad Feature flags
    it should be understood as Microsoft Indic OpenType recommendations.
    The IndiX Indic OpenType implementations are able to convert a character
    syllable (in visual order) to appropriate glyphs from the OpenType
    font in a single pass without any Feature flags and no back and forth
    interaction. This is possible because Indic script shaping can be
    expressed as productions from a Context Sensitive grammar. The OpenType
    substitution tables appear to be implementations of such productions.

    This is what Philippe Verdy means when he says:
       "A generic OpentType font renderer can then be used even for complex scripts
       that it even does not know, and for which no script-specific features are
       recognized and treated specially."

    On Mar 17, 2006 4:00 PM, Antoine Leca said:
       "When it comes about Indic scripts rendering, there is another (industrial)
       "Standard" which is much more relevant, it is the Open Type specifications."

    In TUS, Indic script rendering should better be described using a formal grammar,
    maybe Context Sensitive, but possibly Context Free. Formal grammars are not
    new to TUS. TUS has used Regular Expressions in Annexe #29 Text Boundaries.
    From such a specification, Uniscribe or any other software
    can implement the shaping according to their layering architecture, font model and interfaces.
    TUS for Indic script rendering with the least powerful grammar will also
    show up people who use a sledge-hammer to break a nut.
    AAT is based on (Extended) Finite state machines and corresponds to (Extended?)
    Regular expressions. AAT appears to be much more compact and efficient.
    The formal model behind OpenType is probably Context Sensitive grammar.
    But implementors get so immersed into the OT technology to believe and proclaim
    that a Half Ka Glyph appears in the rendering of Devanagari text because
    a stupid flag called HALF is set!
    Microsoft Indic OpenType recommendations should not be the
    standard for Indic text rendering.

    A pioneer can be excused of following round about tortuous paths. But it is
    up to ohers to imbibe what the pioneer has shown, straighten the paths,
    and simplify the walk. Microsoft and Adobe
    introduced OpenType for complex scripts (Bless them). But abstract, improve and progress
    from their example as well as that from Apple, TeX and many other complex script shaping

    > OpenType Layout tables were not designed to support re-ordering, and that
    > should not be attempted in the font. Font implementers should follow the
    > OpenType font recommendations -- these should be treated like a standardized
    > API: interoperability is built on having implementations working from the
    > same assumptions.

    > Peter Constable

    When a font table implementor reorders the glyphs with lot of pain, she
    is not breaking the OpenType specs or introducing new ones. Recently
    there was some addition to Volt wherein existing capability was made available
    with a simpler interface. Similarly Volt (a tool from Microsoft for creating
    OpenType tables) can support tables with reordering. This will not need extensions
    to the OpenType specs.
    When she reorders glyphs in the font, she is breaking the recommendations
    of the shaping pipeline of Uniscribe. An API like that of Uniscribe is interoperable
    within it with complexity moved from font layer to the character level and its tortuous
    interaction with the lower font layer.
    But others like IndiX have other set of API. The design criteria we try to follow
    are 1) back and forth interaction should be avoided if possible 2) interaction should
    not specify more than what is minimally necessary 3) a problem arising at a layer
    should be solved at the layer itself.

    It would be nice if third party components like an OpenType Indic font have a standard.
    Microsoft has not released that standard but it can be inferred from the interface that they
    specified. The initial interface specifications indicated a one pass architecture with
    substitution tables tagged with specific Feature flags like HALF. But down the line, with
    other scripts, the field got muddled. That is why TUS should specify the Indic text
    rendering formally, with a Context Sensitive grammar. A font designed by Philippe Verdy or IndiX would be much more closer to such a standard.

    Vinod Kumar

    पृथिवी सस्यशालिनी
    Prithivi Sasyashalini

    This archive was generated by hypermail 2.1.5 : Thu Mar 23 2006 - 04:50:39 CST