W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > September 2010

RE: [woff] Action 25: Tighten the description of the private data block

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Wed, 29 Sep 2010 14:35:02 -0400
To: John Daggett <jdaggett@mozilla.com>, www-font <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D049DD3134E@wob-email-01.agfamonotype.org>
Thank you, John.

I agree with your proposed changes, with one suggestion to replace all references to "file blocks" with "data blocks" to keep the terminology consistent with the rest of the spec.

Regards,
Vlad


> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of John Daggett
> Sent: Wednesday, September 29, 2010 10:27 AM
> To: www-font
> Subject: [woff] Action 25: Tighten the description of the private data
> block
> 
> Action 25: Tighten the description of the private data block
> http://www.w3.org/Fonts/WG/track/actions/25

> 
> The current working draft does a good job of disallowing extraneous
> data but
> doesn't explicitly disallow overlapping blocks or font tables.
> 
> I would suggest the following changes:
> 
> In Section 2, "Overall File Structure":
> 
> > 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. 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 between the font tables and data blocks as pointed to
> > by the header and table directory entries, or beyond the last such
> > table or data block. If such extraneous data is present, a conforming
> > user agent MUST reject the file as invalid.
> 
> Change to:
> 
> A complete WOFF file consists of several blocks: 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. Except for padding
> with
> a maximum of three null bytes in places where 4-byte alignment of a
> table length or data block is explicitly permitted, there MUST NOT be
> any extraneous data between file blocks or font data tables. If such
> extraneous data is present a conforming user agent MUST reject the file
> as invalid.  Files with overlapping file blocks or font tables MUST
> also be rejected, along with files containing file blocks that extend
> beyond the end of the file.
> 
> In Section 3, "WOFF Header":
> 
> > If the offset and length fields pointing to the metadata or private
> > data block are out of range, indicating a byte range beyond the
> > physical size of the file, a conforming user agent MUST reject the
> > file as invalid.
> 
> Change to:
> 
> If the metadata or private data offset and length fields indicate byte
> ranges that overlap other file blocks or extend beyond the end of the
> file, a conforming user agent MUST reject the file as invalid.
> 
> In Section 4, "Table Directory"
> 
> > The sfnt-based format specifications require that font tables be
> > aligned on 4-byte boundaries. Font tables whose length is not a
> > multiple of 4 are padded with null bytes up to the next 4-byte
> > boundary. Font data tables in the WOFF file have the same
> requirement:
> > they MUST begin on 4-byte boundaries and be zero-padded to the next
> > 4-byte boundary. The compLength and origLength fields in the header
> > store the exact, unpadded length.
> 
> Append this sentence:
> 
> If the offset and compLength values indicate a byte range that overlaps
> other file sections or font tables, or if the byte range extends beyond
> the end of the file, a conforming user agent MUST reject the file as
> invalid.
> 
> I think that should cover all the places that needed tightening.
> 
> John Daggett

Received on Wednesday, 29 September 2010 18:38:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 September 2010 18:38:59 GMT