[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Starting work on the OpenType code
From: |
Owen Taylor |
Subject: |
Re: [ft-devel] Starting work on the OpenType code |
Date: |
Fri, 01 Apr 2005 15:29:22 -0500 |
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
RE: [ft-devel] Starting work on the OpenType code, Behdad Esfahbod, 2005/04/04