Re: [Devel] OpenType futures

[Werner LEMBERG]

> The API I'd like to see is:
>
>  - Low-level; doesn't handle layout logic or language-specific logic
>    but just the application of OpenType features.
>
>    An API in the FreeType style that does language-specific layout
>    is certainly a legitimate project, but its not something I could
>    get time to work on, since its just duplicating what is already
>    in Pango.

In case we provide a separate library this isn't indeed an urgent
task.

>  - OpenType specific.  The structure of scripts, features, lookups
>    in OpenType needs to be exposed.
>
>  - High performance.  The data structures need to be structured for
>    doing OpenType features as fast as possible.  The OTL_Buffer
>    description I mailed out recently describes how I think that
>    should work.

Since you have the most experience, just go on.

> Now, there are two basic ways I know of to approach sharing
> the current code:
>
>  - Integrate the code as part of FreeType using direct
>    access to FreeType internal data structures. This has
>    been done in the LAYOUT branch of freetype2, though
>    I don't really agree with all the details.
>
>    The advantage of this is that it is less work (since the
>    code currently works this way), and distribution is
>    simple; you get a new version of FreeType, you get
>    a new version of the code.
>
>  - Take the code and make it work on memory buffers rather
>    than FreeType streams, and distribute it separately
>    from FreeType. David started doing this in the 'otlayout'
>    module in CVS.
>
>    The advantage of this is that it is decoupled from FreeType
>    development; changes can be pulled into projects without
>    waiting for a release of FreeType; users aren't forced
>    to upgrade their FreeType. This could even be done outside
>    of the FreeType project (at freedesktop.org, say)
>
> Either way could be managed for Pango, the second is easier
> to deal in the short term, certainly. I'd really like to hear
> from David and Werner what they think the path forward
> should be.

I strongly prefer the latter.  Do we agree that FreeType's job is to
validate the tables, and that the otlayout library expects validated
tables?  This is, the stuff in FreeType's src/otlayout directory
should be made working, serving as a basis for the otlayout library.


     Werner