W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: WebOTF Proposal

From: Jonathan Kew <jonathan@jfkew.plus.com>
Date: Fri, 7 Aug 2009 01:05:53 +0100
Cc: Tal Leming <tal@typesupply.com>, www-font <www-font@w3.org>
Message-Id: <1CA461C7-F2CA-49D2-B6B1-281F94C4AB77@jfkew.plus.com>
To: Thomas Lord <lord@emf.net>
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?


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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:33 UTC