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

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

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Wed, 29 Sep 2010 10:42:53 -0400
To: "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D049DD31227@wob-email-01.agfamonotype.org>
Forwarding to the WG email list.


-----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 14:45:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 September 2010 14:45:46 GMT