Re: [Devel] OpenType futures

[Owen Taylor]

On Wed, 2004-08-11 at 19:31, Werner LEMBERG wrote:
> > We have three operations that need to know the details about the
> > data structures for individual lookups:
> >  
> >  - The code to validate the table
> >  - The code to parse the table (which is a subset of validation)
> >  - The code to apply the lookup to glyphs
> > 
> > No matter how we group them it seems a bad idea to put different
> > parts of these operations in different libraries.  Adding support
> > for new lookups or fixing bugs in existing lookups might well then
> > require fixes in two places and two releases.
> 
> Maybe a misunderstanding.  As you've mentioned in another mail, ICU
> just parses the table without validating at all.  What I suggest is
> that the otlayout library opens a font and asks for validation of the
> OpenType tables in a font, then the otlayout library requests the raw
> OpenType tables.  The validation happens only once; in case a font has
> to be closed and reopened, otlayout could cache the validation result.
> I don't think that the speed impact of validating is serious, but it
> makes coding the otlayout library simpler since you can throw out all
> runtime validity tests.

I understand the approach, I just don't see why you think that putting
part of the work in FreeType and part in a separate library makes
sense. 

There doesn't seem to me to be any reason why validation is inherently
easier to do inside FreeType. To do table parsing inside FreeType takes
a stream. To do table parsing outside of FreeType takes a buffer. To do
validation inside FreeType takes a stream. To do validation outside
FreeType takes a buffer and a length. 

It doesn't seem likely to me that there will be multiple consumers of
the table validation code. Yes, there are multiple other OSS
implementations of OpenType lookup code now (ICU, yudit) but are they
really going to be rewritten to depend on some portion of the necessary
code if that appears in FreeType. And really, the code to do the lookups
is the hard code, the code that we really want to share. 

So, I don't see big advantages. And I do see big costs.

For one example, to make the addition in:
 
 http://bugzilla.gnome.org/show_bug.cgi?id=149696

Would require modifying both libraries in your scheme. And if Pango
started using the new otlayout on a system without a new FreeType it
might be parsing unvalidated tables.

For another example, say we started off with an approach that was
basically:

 FT_Face_Get_Validated_Table (gsub)

And then found that validating everything upfront was prohibitively
expensive and wanted to switch to something more along the lines of:

 FT_Face_Get_Validated_OT_Lookup (gsub, 3)

Then we are going to have to change both libraries and going to end
up with a case where otlayout-1.1 only works with FreeType-2.2.5
or newer. Creating dependency nightmares for very little positive
gain.

> IMHO, validation should be done completely separated from parsing;
> similar to ICU, I imagine that the otlayout library parses the
> OpenType tables on the fly which means that during the lookup process
> only a small part of the OpenType tables will be parsed -- I don't
> consider parsing as a subset of validation at all.  

The code obviously is different but they both require access to the
font data, they both require understanding the structure of the
OpenType 

> Handling OpenType
> tables similar to FreeType 1 and doing validation too is nonsense, of
> course.http://bugzilla.gnome.org/show_bug.cgi?id=118592
> 
> Both Qt and Pango have working OpenType engines, and I don't think
> that the OpenType standard will change significantly in the near
> future.  

I don't know about Qt, but I'm still actively finding and fixing
problems in the OpenType code in Pango. I've made some good sized
structural changes. I'd like to make a some more. Fixing a bug
like:

 http://bugzilla.gnome.org/show_bug.cgi?id=118592

in just one copy of the code is not a good idea.

> With other words, producing a short term solution doesn't
> appear very urgent to me.  I really suggest to do it the `right' way,
> probably at the cost that it will take more time to make it work.  The
> output of the new code can always be compared with the results of Qt
> and Pango (and ICU, of course), which should help a lot.

To me, it's a lot easier, if we want both a new API / code organization
and a new internal structure that avoids an initial full parse,
to do the first first, then do the second. Then I can actually try
out the new code and check:

 - Is it producing the same results
 - Is it performing OK?

And know that the comparison is really apple-to-apples.

I also think it's a lot better if someone is working on a rewrite
can reference a single code base that is known to have all bug fixes.
Work that has been done in otlayout/ and src/otlayout/ has been
done based on the Pango-1.2 or the freetype1 code. These are code bases
that are really buggy compared to the current Pango code.

The way I'd like to proceed is:

 - We figure out an API that is going to work for Pango, for Qt, and
   for separate validation.
 - We implement that in otlayout/ using the currently working code.
 - Bug fixes and improvements that are being done for Pango or Qt can
   land immediately in that code base.
 - In parallel, a rewrite to separate validation can be done using
   the same application API, and when its reasonably complete, it
   should be very easy to drop into place.

Regards,
                                        Owen

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