Re: Windows Glyph Handling

From: Edward H. Trager (
Date: Thu Aug 25 2005 - 12:30:18 CDT

  • Next message: David Starner: "Re: Windows Glyph Handling"

    On Thursday 2005.08.25 01:42:25 +0200, Adam Twardoch wrote:
    > Christopher Fynn wrote:
    > >If one wants to Microsoft's shaping engine (Uniscribe) for a
    > >particular script then that script has to be already supported (or one
    > >has to wait for Microsoft to add support) - and, in the font, one has
    > >to use lookups only under the particular sub-set of OT features
    > >Uniscribe actually supports for that script.
    > >
    > >For unsupported scripts, applying OT shaping to PUA characters and so
    > >on in MS Windows there aren't many choices: 1) Try to find an
    > >application supporting a font and shaping system where you can put all
    > >the necessary logic into the font tables (GRAPHITE, AAT) and use
    > >that. 2) Find an application using an open source OpenType shaping
    > >engine (like Pango or ICU) and add your own code to enable shaping
    > >support for the script / characters you need. 3) Wait for Microsoft to
    > >add support for your script in Uniscribe.
    > >
    > The real problem is: even if the IndiX, Pango and ICU developers got

    The Indix that one can download from TDIL (
    is still based on GTK+1.2x whereas
    current versions of the GTK+ toolkit are somewhere around 2.4x. The fact that
    Indix appears to not be synchonizing their code to keep pace with the rest of
    the Linux world (or at least rest of the Linux Gnome/GTK world) makes me think that Indix
    is not going to materialize as a long-term solution in India or anywhere else.

    Besides Pango and ICU, you neglect to mention M17N (
    Also my understanding is that the Pango and ICU developers do in fact communicate
    to insure, for example, that improvements in Indic script rendering make it
    into both the Pango and ICU code bases. It would be better though if they unified
    their efforts into a single library for text layout. Also, it might help if the Pango
    and ICU developers took a close look at what the M17N developers have done (For example
    M17N has support for Myanmar layout which, when I last checked, Pango and ICU still
    lacked). My understanding is that with M17N it is possible to add
    new shaping rules for scripts without having to recompile the whole M17N library.
    Unfortunately, I haven't had time to look at the details nor evaluate if this
    kind of convenience results in a performance penalty or not.

    > together and specified shaping rules for writing systems not supported
    > by Uniscribe, such an effort would be doomed because, should Microsoft

    I don't believe such an effort would be "doomed" (to use your choice of words).
    The GTK+ toolkit (with Pango for text rendering) has already been ported to
    Windows, thus opening a number of very good Open Source applications to use
    by users of Microsoft operating systems. And do not forget that OpenOffice
    uses ICU's layout engine.

    The problem in my mind is that the vast majority of people continue to expect
    commercial software vendors to provide them with solutions to their problems
    in a timely manner. The reality, depending on what problem you want
    solved, is that the commercial software vendors are not necessarily going to
    solve it for you in the kind of time frame that you want, if they choose to
    solve it at all.

    On the other hand,
    the current state of Open Source is also not as encouraging as it could be: I can think of at
    least six projects that aim, to one degree or another, to provide text layout
    services for complex text layout scripts:
    Pango, ICU, M17N, Indix, Graphite, and --don't forget-- FreeType Layout
    ( , still vaporware I think). Trolltech's
    QT Open Source framework also has complex text layout (so that would be seven).
    And I probably should not forget Mozilla Firefox (which uses something called
    "Pango Lite" on non-MS platforms but Uniscribe on MS platforms), so that's eight.
    For complex Indic- and
    Indic-derived scripts, I would not be surprised if everyone of these libraries had
    at least a few bugs, and the bugs could be different for each one of them. Well,
    that's the nature of "evolutionary" systems like Open Source!

    The developers of all of these Open Source text layout/text rendering
    projects (plus the Firefox developers) need to get together for a week-long meeting
    to hash out a proposed standard, an API, and a library for dealing with text layout
    once and for all. That library could, for example, be designed from day one to support
    all of the OpenType features that should be supported while also perhaps supporting
    Graphite and M17N features where it makes sense to do so.

     - Ed Trager

    > no guarantee they would follow that implementation. (Actually, one could
    > even presume they would NOT follow it).
    > Currently, there is an international character encoding standard
    > (Unicode/ISO 10646) and there will soon be an international standard for
    > digital glyph storage in a font format (with OpenType being
    > standardized). However, the "glue" between these two is a proprietary
    > Microsoft technology, with no proper submission process and unsufficient
    > resources within the Microsoft Typography group.
    > Regards,
    > Adam

    This archive was generated by hypermail 2.1.5 : Thu Aug 25 2005 - 12:19:32 CDT