Re: [Devel] Regarding the layout table formats & FreeType 2

[David Turner]

Hi Antoine,

Antoine Leca wrote:
> Hi George,
>
> George Williams va escriure:
>
>
> > This may be because GX doesn't really have the range of positioning
> > possibilities available in OpenType. It has 'kern' and 'opbd' and
> > that's about it.
>
>
> Sorry to ask you more contribution: I would like being able to figure it
> myself, but my knowledge on GX is simply much too limited.
>
> Can you imagine that every possibility of GX (in this area, i.e. as exposed
> by this API) might be implemented on a subsequent OpenType font, decomposing
> it into a series of actions dealing with OpenType features?

This is simply not possible. The gap between these two technologies is so
large that they cannot be converted easily into one another, at least in
a general way. Of course, that doesn't mean that a font editor shouldn't be
able to generate both kind of tables from a single higher-level description.

The tables themselves are used in very distinct ways:

  - with GX, the client doesn't need to know much about languages
    and scripts, because all the information is embedded into the font.

    As an example, bi-directionnal text support is coded directly within
    the font file (it includes a property table that gives the bidirectionnal
    class of every _glyph_ (not character) in the font. This implies that
    a working GX layout engine needs a specific BIDI re-ordering algorithm
    that doesn't rely on Unicode values.

    Another striking difference is the management of features: in AAT/GX, all
    features are user-selectable. I won't detail these here though.


  - with OpenType Layout, the client must know a _lot_ about scripts
    and languages. It must also apply certain features, in specific order,
    depending on the current "language" for the run. See the following page
    for all the gory details:

      http://www.microsoft.com/typography/specs/

    look under "Specifications for creating and supporting OpenType Fonts for:"
    to retrieve the behaviour of client applications & libraries. It is far
    from trivial. By the way, I'm not even sure that Pango's current behaviour
    matches the algorithm described in these pages for all scripts (?)

    Also "OTL features" are very strange things. Some of them are required by
    scripts/languages, while others defined in the feature registry seem to be
    user-selectable. It's actually very difficult to tell. And of course, 
there's
    the atrocious requirement of specifying weird "properties" to glyphs. Huh..

In other words:

  GX is:
       - hard to implement
       - easy to use
       - makes font table generation hard (and probably large)

  OTL is:
       - hard to implement
       - hard to use
       - makes font table generation easier (and probably shorter)

  They're also widely incompatible.

Of course, that's just my opinion. You can also read Dave Opstad's one
at the following address:

  http://developer.apple.com/fonts/WhitePapers/GXvsOTLayout.html


> If the answer is yes, this may beg to a 2-level API, at the lowest some way
> to access the OpenType features and dealing with them, and at an higher
> level something that will look like Masatoke's work, whose action would be
> direct on a GX font while decomposed in a raw of more "simple" ones in the
> case of a OpenType one.
> The whole picture might well be attracting, isn't it?
Yes, but it won't be practical. And I guess it will very easily confuse users,
because I suspect that most of them won't be extreme specialists in OTL and GX 
:-)

> However, if the answer is no, well we are rushing ourselves into David's
> option, having two separate APIs (which will certainly make no favour to GX
> as a technology)
I prefer that one, unless someone can give me another explanation on how the
technologies work :-(

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)