Re: [Devel] OpenType futures

[Lars Knoll]

On Wednesday 11 August 2004 04:42, Werner LEMBERG wrote:
> > 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.

That would be what I'd like to see as well.

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

This is rather important. Both pango and Qt have modified the original OT code 
to improve performance.

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

I'm fine with this being a separate project, either within the freetype CVS or 
within fd.o. 

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

Having validated tables would surely make the code in the otlayout library 
easier. On the other hand it just moves complexity from one place to the 
other, so I am rather neutral as to where the validating code should be.

Should the otlayout code work directly on the tables from the font file? Or do 
we want to keep the way we currently have and parse a good part of the 
tables? In the long term it sounds nicer to directly work on the unparsed 
tables.

Cheers,
Lars