[Devel] OpenType futures

[Owen Taylor]

I'd really like to move ahead with moving the maintenance of the
OpenType code to a shared location. I've made various fixes
recently. There are more fixes and changes in the pipeline.
The longer that moving to a shared codebase waits, the harder
it is to do.

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.

 - 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.

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.

Thanks,
                                        Owen

signature.asc
Description: This is a digitally signed message part