comments on WOFF File Format 1.0, W3C Working Draft 27 July 2010

Comments on WOFF File Format 1.0, W3C Working Draft 27 July 2010:

Abstract

> This format was designed to provide lightweight, easy-to-implement
> compression of the font data, suitable for use in conjunction with
> the @font-face CSS declaration.

I would suggest [font data] instead of [the font data] and replace
[for use in conjunction with the @font-face CSS declaration] with [for
use in CSS @font-face rules].

> Any TrueType/OpenType/Open Font Format file can be losslessly
> converted to WOFF for Web use (subject to licensing of the font
> data); once decoded by a user agent, the WOFF font will display
> identically to the original desktop font from which it was created.

I would suggest:

Any properly licensed TrueType/OpenType/Open Font Format font can be
losslessly compressed into a WOFF font for web use.  User agents
restore the original font such that it will display identically to the
original font from which it was created.

> The WOFF format is not expected to replace other formats such as
> TrueType/OpenType/Open Font Format or SVG fonts, but provides an
> alternative solution for use cases where these formats may be less
> performant, or where licensing considerations make their use less
> acceptable.

Replace [expected] with [intended] and [performant] with [optimal].

2. Overall File Structure

> Except for padding with a maximum of three null bytes in places
> where 4-byte alignment of a table length or data block is specified,
> there MUST NOT be any extraneous data outside the font tables and
> data blocks as pointed to by the header and table directory entries.

Change [outside the font tables and data blocks] to [between font
tables or other data blocks].

I think we should add an explicit check for this and put that in
Section 8:

User agents MUST NOT load WOFF files that contain extraneous data
between font tables.

Append at the end of the section:

All sizes described in this document are assumed to be in bytes unless 
otherwise noted.

3. WOFF Header

> Note that this value MUST be a multiple of 4, because all font
> tables including the last are to be padded to a 4-byte boundary. If
> this value is incorrect, a conforming WOFF processor MUST reject the
> file as invalid.

Here and in several other places the term "WOFF processor" is used
without a clear definition.  I would suggest just using "user agent"
throughout the document, that has an already defined meaning for W3C
specs.

4. Table Directory

> Font data tables in the WOFF file have the same requirement: they
> MUST begin on 4-byte boundaries and be padded with nulls to the next
> 4-byte boundary.

Maybe "... and be zero-padded to the next 4-byte boundary" would be simpler?

> The sfnt-based font specifications require that the table directory
> entries are sorted in ascending order of tag value.

Trim [the].

Checksums

Section 4 contains this paragraph:

> sfnt-based fonts store a checksum for each table in the table
> directory, and an overall checksum for the entire font in the head
> table (see the TrueType, OpenType or Open Font Format specifications
> for the definition of each calculation). Tools producing WOFF files
> MUST validate these checksums, and correct the values and/or issue
> an error message if a discrepancy is found.

But in Section 8, "Summary of Conformance Requirements", origChecksum has
this requirement:

> MUST be correct for the original table data, in accordance with the
> OpenType specification

If a tool just issues a warning, the checksum won't be correct.  If a
tool must not produce a WOFF font in this case, that needs to be
explicit.

I think it's reasonable to require tools to validate checksums but I
would prefer that user agents not be *required* to validate checksums,
I think that's really part of the font validation/sanitizing process
that's outside the scope of this spec.

Appendix B and Appendix C

Are these sections informative or normative?  The "best practices" title
suggests they are informative but the discussion is a mixture of
normative procedures and suggested practices.  I think it might be
better to fold these two sections into Section 8, carefully
distinguishing suggested best practices from normative requirements. 
List conformance requirements followed by notes for tools, then notes
for user agents.

Footnote style

I would suggest just using [n] without superscripting or underlining.

Received on Wednesday, 4 August 2010 07:45:21 UTC