proposed edits to WOFF specification

In preparation for our next meeting, I have begun making edits to the WOFF specification document in the light of last week's discussions. Here is a summary of the main changes I've made in my local copy at this point.

* I won't post individual diffs here, but I have replaced all occurrences of "WOFF font" or "WOFF font format" with "WOFF file [format]", as appropriate. I'll be happy to post a complete edited draft somewhere....

* I have NOT yet added any text regarding embedding permissions/the fsType bits, as I have not felt that there is any clear consensus that we should do this, or (if so) exactly what should be said.

0. Abstract - updated text

<p>This document specifies WOFF, a container format for sfnt type fonts such as
OpenType. This format was designed to provide lightweight, easy-to-implement
compression of font data, suitable for use in conjunction with the <span
class="code">@font-face</span> CSS declaration. 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 file will
display identically to the original desktop font from which it was created.
Unless the original font file is constructed with anomalies such as incorrect
checksums or unreferenced gaps between tables, the decoded WOFF file will be
bit-for-bit identical to the original font.</p>

<p>The WOFF format also allows additional metadata to be attached to the file;
this can be used by font designers or vendors to include licensing or other
information, beyond that present in the original font. Such metadata does not
affect the rendering of the font in any way, but may be displayed to the user on
request. In addition to standardized metadata, a block of private data may be
attached; this may be used by the designer or vendor for any purpose, but will
not be interpreted or used in any way by user agents or other processes except
by private agreement. Neither metadata nor private data affect the loading or
rendering of the font by user agents.</p>

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


1. Introduction - updated text

<p>This document specifies a simple compressed file format for fonts, designed
primarily for use on the web.  The WOFF format is a container for the
table-based sfnt structure used in TrueType<a id="fn-1-ref" href="#fn-1"
title="footnote 1" class="fnref">[1]</a>, OpenType<a id="fn-2-ref" href="#fn-2"
title="footnote 2" class="fnref">[2]</a> and Open Font Format<a id="fn-3-ref"
href="#fn-3" title="footnote 3" class="fnref">[3]</a> fonts, which are
collectively referred to as sfnt-based fonts. A WOFF file is simply a repackaged
version of a sfnt-based font with optional compression of the font data tables.
The WOFF file format also allows font metadata and private-use data to be
included separately from the font data. WOFF encoding tools convert an existing
sfnt-based font into a WOFF formatted file, and user agents restore the original
sfnt-based font data for use with a webpage.</p>

<p>In general, the structure and contents of decoded font data exactly match
those of the original font file. Tools producing WOFF files may provide other
font editing features such as glyph subsetting, validation or font feature
additions but these are considered outside the scope of this format. Independent
of these features, both tools and user agents must assure that the validity of
the underlying font data is preserved.</p>


2. Overall file structure, paras 2-3 - made ordering more explicit, compression is optional:

<p>The main body of the file consists of the same collection of font data tables
as the original, uncompressed sfnt-based font, stored in the same order, except
that each table may be compressed, and the sfnt table directory is replaced by
the WOFF table directory.</p>

<p>A complete WOFF file consists of a 44-byte header, immediately followed (in
this order) by a variable-size table directory, a variable number of font
tables, an optional block of extended metadata, and an optional block of private
data.</p>


3. WOFF Header

(a) Note that examples of "flavor" field are merely "typical", not the only valid values:

<tr><td>UInt32</td><td>flavor</td><td>The "sfnt version" of the original file,
typically 0x00010000 for TrueType flavored fonts or 0x4F54544F <span
class="code">'OTTO'</span> for CFF flavored fonts.</td></tr>

(b) Drop clarification of the majorVersion and minorVersion fields from the table, leaving this to the following text.


4. Table directory

(a) Note possible exception to 100% round-trip fidelity

<p>In general, WOFF-producing tools generate a WOFF file with the same set of
tables as in the original font. This means that the overall font checksum of a
font decompressed from a conformant WOFF file should always match the checksum
in the original, valid sfnt-based font file, except in the case where the
original file included unreferenced data between or after the actual tables;
this would affect the overall checksum of the original font, but would be
dropped during creation of the WOFF file.</p>

(b) Add paragraph to explicitly require round-trip fidelity for normal fonts:

<p>Unless the original font has incorrect checksums that are corrected by the
WOFF file generator, or extraneous data between tables (discarded by the WOFF
generator), the result of creating a WOFF file and then decoding this to
regenerate an sfnt font MUST result in a final font that is bitwise-identical to
the original.</p>


5. Font data tables - add clarifying paragraph (after para 1)

<p>User agents or other programs that decode WOFF files MUST be able to handle
tables that have been compressed. However, the use of compression for font data
tables is optional for tools generating WOFF files; storing the tables in
uncompressed form is permissible.</p>

Received on Tuesday, 18 May 2010 22:31:56 UTC