Re: [Devel] OpenType futures

[Antoine Leca]

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)

If we do validation apart from parsing, we will duplicate the effort of
conversion, won't we? 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. I
do not expect these data structures to be big, nor to have much
controversies about how to expose this (OTOH, I expect diversity when we go
one level deeper, as Lars mentionned): the only complex thing to me are the
extensions that were added with OpenType 1.3 to pass the 64K barrier, and
this area seems so tricky that probably having this job done only once in a
central place is probably a good idea ;-); furthermore then the "clients"
would ideally not have to worry about having to search after a table in the
main part or through an extension.


Antoine