Re: [Devel] OpenType futures

[Owen Taylor]

On Wed, 2004-08-11 at 07:40, Antoine Leca wrote:
> Werner LEMBERG answered Lars:
> > > 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.
> >
> > IMHO the otlayout library should work on the unparsed but validated
> > tables.  Maybe the validation process can fill some basic structures
> > with important values (offsets, number of features, etc.) which speed
> > up the access.
> 
> There is something I always have in mind: OT tables are in Motorola order
> (and use quite a bit 16-bit values), while a good number of implementations
> would be on Intel order with 32-bit values preferred. I did not make any
> timings, but my idea is that the extraction of the datas from the raw format
> is an important part of the total time (I appreciate numbers on this)

It's hard to get numbers for this from the current code that Pango and
Qt use, because that code *does* pre-parse the tables into a native
format.

In theory you could compare the performance of ICU layout, which 
parses on the fly (without validation at all!) with the 
freetype1/Pango/Qt code, but there are so many other factors involved,
it would be hard to compare.

> If we do validation apart from parsing, we will duplicate the effort of
> conversion, won't we? 

Duplicating the effort of conversion twice isn't what concerns me. The
question is whether duplicating the effort of conversion *every* time
you apply a particular feature lookup is going to be prohibitive.

> I do not know what is the scheme(s) you might have in
> mind, though (for example, a scheme where validation passes automatically
> when the font is on some location, say ROM on embeeded machine, might be
> conceived). But with my idea the whole tables should be checked at least
> everytime the font is openned. So perhaps a result of validation that
> exposes the tree structure (scripts, languages, features, lookups) with
> direct pointers/offsets to the (validated) raw datas would be interesting.

In general, OpenType fonts contain very few byte-sized quantities; 
its almost all 16-bit quantities. So, there might not be much advantage
to pointing back to the original font, at least on little-endian
machines.

> I do not expect these data structures to be big, nor to have much
> controversies about how to expose this

If you mean to extend all the way down to the levels of individual
lookup types, these data structures are as big as the OpenType spec ...
see:
 
http://cvs.gnome.org/viewcvs/pango/pango/opentype/ftxgsub.h?view=markup
http://cvs.gnome.org/viewcvs/pango/pango/opentype/ftxgpos.h?view=markup

OpenType looks vastly simpler at the level of "apply feature 'blws' to
this array of glyphs" than at level of parsed tables. I don't think
the parsed tables should be part of a public API.

Regards,
                                                Owen

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