Re: WebOTF Proposal

On Thu, 2009-08-06 at 15:10 -0400, Tal Leming wrote:
> We, (Jonathan Kew, Erik van Blokland and myself) have combined our ZOT  
> and .webfont proposals into a new WebOTF proposal. The full  
> specification is attached.

I am curious if you considered a particular 
alternative to table compression. Namely:

Whole file compression is not incompatible with
a degree of random access to a file.  bzip2
and gzip offer support for this.

Whole file compression is normally handled
lower in the stack, in a generic way.  (I
guess the term of art is "at the request layer").
At that layer, the decompression magic needed
to perform random-access, partial reads of 
the uncompressed resource can be hidden from
font code.

Providing the random access magic is at a
lower layer is a cleaner, more general approach:
it can be re-used for other media types.

Whole file compression with its way
of handling random access would avoid breaking
the DSIG field.

I also wonder what the density of a "typical"
font subset will be.  If it is large enough 
relative to the chunk size at which generic 
compression supports random access,  it may
less often be necessary to subset at all.

Quantifying the relative performance of the two
approaches would be difficult for a noteworthy
reason: the needs of mobile devices are unclear
in this area, experience lacking, and so no model
of the performance goals is at hand (at least none
reported here).

It would simplify WebOTF to not specify internal
compression at this time but sacrifice little 
since it can certainly be added later.

The simplification could actually be significant
for UAs which are *not* intended for mobile, low-bandwidth,
low-speed, and/or low-memory environments.  For
example, it would be one fewer new dependency between
font processing code and zlib.

Finally, I'm not sure I understand this correctly
but my tentative understanding of *uncompressed*
WebOTF is that aside from skipping the header and
finding the table directory, WebOTF can be processed
directly by an existing OTF processor.  Is that
correct?  That is, the uncompressed version of the
format essentially *is* OTF but sandwiched between
a header and two new tables at the end?

If that is the case, would WebOTF not be improved
if it were reliably possible to generate WebOTF
by simply concatenating three files, the main 
payload being the output from existing OTF generators?
WebOTF as stated would lack that property mainly
because of the new padding requirements and 
requirement to remove DSIG.

-t

Received on Thursday, 6 August 2009 23:27:48 UTC