Re: Representative glyphs for combining kannada signs

From: Antoine Leca (Antoine10646@leca-marti.org)
Date: Thu Mar 23 2006 - 04:09:28 CST

  • Next message: Antoine Leca: "Re: DIY OpenType Re-ordering (was: Representative glyphs for combining kannada signs)"

    Philippe Verdy wrote:
    > I really spoke about OpenType whose most important
    > standard addition if the substitution and positioning tables.
    >
    > To implement those tables, you don't necessarily need to have a
    > stable set of rules, simplied in standard "feature" tables.

    Agreed. One of the most important specificity of OpenType is that the use of
    the table datas relies on the "application software".

    However there is a little problem in the middle of the road.
    Except some very specific cases (like OTLS or ADK), the tables are not
    easily accessible from user application software, while they are pretty
    easily available for system softwares. Those softwares (Uniscribe, ICU
    LayoutEngine, Pango) are really applications when seen from the main drawing
    engine (GDI, whatever, X11 or Freetype, respectively), but their behaviour
    as seen by normal developpers or plain users is those of a system software.

    Furthermore, to ensure interoperability (a very desired feature), one has to
    casts some rules in stone. It was decided to use the TrueTypeOpen
    architecture for complex script layout. The result is that those system
    software sort-of take precedence over the use of the OpenType tables, in the
    case of complex scripts.

    Sure you can go the same road again and reinvent the same wheel to render
    complex scripts; Graphite does about exactly that, so I believe Peter is
    qualified to explain in much more details how complex it can be.
    You can even use the OpenType architecture for that use (my guess is that
    other developpers did avoid it to avoid IP battles with Microsoft; as well
    as the not-invented-here syndrom.) It certainly would work somewhat, at the
    end of the day.
    I am not sure it would be definitively better.

    I am just sure it would NOT be interoperable; that means, *no font* to begin
    with. So your chance of having many users, at this point of the history, are
    pretty thin.

    The decision to use TTO for complex scripts is dated 1994 1.

    > Just common tables, out of any "feature", would do the trick,
    > without requiring special interpretation according to the script
    > or feature label in the opentype font, implemented in the text
    > renderer.

    Well, no.
    Just have a look at GX solution _and implementations_ for the problem of
    reordering should give you a hint that it is NOT easy. (Yes Dave/John, it
    *is* elegant.)
    Since OpenType is a bit less rich in functionnality here: it cannot easily
    specify a reorder involving four glyphs, with ignored context in the middle,
    for instance (and here I am ignoring the fact that the font construction
    tools, like VOLT, are even one or several step back); the resulting solution
    will be /quite/ heavy. I remember reading MS engineers (think it should be
    S.M.) talking about some tries they did along this way, performances were
    awful, the engine was really spending all the machine time interpreting
    numerous OpenType lookups.
    It is not efficient. And the resulting tables are real bloat (also, it
    exceeded the 16-bit limit of TTO ;-).)
    Flexible and elegant, but inefficient.
    Artistic, but not industrial.

    > As long as there's a standard OpenType renderer, it would work even
    > in absence ofspecific support for the script in the renderer: the
    > renderer just has to use the subst/posn tables asthey are implemented
    > in the font,and the renderer does not ned to infer more complete
    > tables from a reduced set of rules encoded in a feature.

    That is almost exactly the GX/AAT way.
    Read about the war between OT and GX in the years 1994-96, it is full of
    arguments one way or the other.
    But the war is over.

    > Of course this means that this single feature in the font will
    > not be under control of the application.

    Why not? Every OpenType-enable application is, at the very least, able to
    slect the "feature" it want to be applied or not (and most "real" ones give
    the user a hand to it). Just unselect your "Indic rendering" features, and
    you are done. No mess done, the application can do it itself.

    Which is what Charmap should have done in the first place.

    Perhaps, one can toggle this feature, defining ETO_IGNORELANGUAGE as the way
    to unselect this feature...

    > So the applicationfor example will not be able to
    > control whever ligatures should be honored, or if language-specific
    > rules or subsets of ligatures should be enabled, replaced, or

    Just design a number of features to do each and every of these tasks, make
    them enable by default, and you are done.
    By the way, an application which does Indic rendering (like Uniscribe, or
    more to the point ICU LayoutEngine) is free to decide to apply, or not, the
    "optional" steps (like most conjunct formation).
    The problem if we go this road, is that we should add a number of feature to
    the renderers, and performances will suffer.
    But it could be a good improvement in the future.
    By the way, it is very easy to enforce this idea: just design those
    optionnal features, register them, and talk to MichKa, Peter, and his team
    to have Uniscribe use them or giving some API way to enable them. Job done.
    Released operationaly in 2010, world-wide (ex-Blackcomb, now Vienna.)

    > When you say that Idon't knowwhat I'm speaking about, it'sjust that I
    > don't use your terminology, or do not participate to OpenType
    > standardisation group.

    I am not sure. The excerpt you gave about Indic rendering is so much an
    oversimplification of the process, that it certainly has a real theoric
    interest, but it fails to address the real scale of the problem.
    And the scale of the problem is exactly what triggers the use of "fixed
    reorderding rules in the renderer" in the first place (which is the very
    point you are fighting.)

    I hope you did make the effort to read al this stance. I thank you at this
    point for having done so. I expect you to try to answer as a whole, not on
    specific points taken out of context.

    Antoine



    This archive was generated by hypermail 2.1.5 : Thu Mar 23 2006 - 04:25:22 CST