Re: [ft-devel] Starting work on the OpenType code

[Owen Taylor]

wOn Fri, 2005-04-01 at 22:26 +0200, Werner LEMBERG wrote:
> > - I'm also not very fond of putting the 'otvalid' module within
> >   FreeType, but Werner's work is valuable in at least one scenario:
> >   someone using FreeType with ICU, which provides its own C++
> >   OpenType parser that doesn't perform a single check with regards
> >   to table validity.
> 
> Well, this has been discussed a longer time ago, and we agreed on
> having OT validation as a module.  IMHO, FreeType *is* the right
> place: A library which accesses OT tables directly without parsing
> them in advance needs completely different structures and access
> methods, so code sharing isn't possible.

The problem that I pointed out at that point is that every extension
to the set of parsed tables is going to require a new FreeType version
*and* a new version of the table processing library. Which is
painful and hard to coordinate.

> > - If you intend to rework the internals later to parse the tables
> >   directly, I'd suggest first reworking the current API to hide as
> >   much details as possible.  This would allow you later to make
> >   drastic changes without requesting yet another big change to both
> >   Pango and Qt.
> 
> Yes.  Yes.  Yes.  :-)

I think there was at least a little bit of agreement that the the
Pango structure of 

 OTLInfo / OTLRuleset / OTLBuffer 

would work well for most people. (OTLBuffer exists in the Pango
OpenType code as a FreeType-level object. OTLRuleset and OTLInfo
exist only as PangoOTRuleset and PangoOTInfo so would have to be
de-GObject-ized.)

Regards,
                                        Owen

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