Re: WebOTF Proposal

On 7 Aug 2009, at 00:27, Thomas Lord wrote:

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

Requiring all user agents to add support for a new format *again*; why  
set ourselves up go through the pain of that extra transition?

> Finally, I'm not sure I understand this correctly

(apparently not)

> 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?

No.

>  That is, the uncompressed version of the
> format essentially *is* OTF but sandwiched between
> a header and two new tables at the end?

No.

> If that is the case,

(which it isn't)

> 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.

No, those issues are beside the point; the padding is harmless (but  
avoids forcing decoders to handle misaligned data access), and a DSIG  
table would also be harmless but is removed because it will not be a  
valid signature.

The table directory, on the other hand, is different (and incompatible).

Next time, I suggest taking the time to understand the proposal before  
writing about it at such length.

JK

Received on Friday, 7 August 2009 00:06:42 UTC