Re: WOFF and padding at the end of the font file

On 8 Jun 2010, at 23:53, Sergey Malkin wrote:

> Looking at some OpenType font files I noticed that they include padding bytes after last table. I checked John Daggets’s web fonts page (http://people.mozilla.org/~jdaggett/webfonts/fonts/), there are at least two of them having this issue: Chunkfive.otf and MEgalopolisExtra.otf. I do not see such fonts shipped with Windows, but digging more into this I found at least two font tools I am using, that are inserting this unnecessary padding.

We encountered this issue last year, and testing of numerous fonts indicated that it DOES appear to be the norm that the last table is padded to a 4-byte boundary.

>  
> “OpenType Font File” section of OpenType specification says: “All tables must begin on four byte boundaries, and any remaining space between tables is padded with zeros.” There is nothing there about padding after last table. This would be ok, nobody is looking there anyway J. But, this makes exact recreation of original font file from WOFF impossible. Only way to get actual length of unpacked font is to add offset of the last table and its length. But this will give you size without padding applied after it, so it will not match length of original file specified in WOFF header.

It seems to me that the OpenType spec is unclear on this; it does not make an explicit statement, but it includes several things that imply such padding is expected. Moreover, my investigations into fonts currently in circulation seemed to suggest that at least one major font production tool (sorry, I forget which) formerly generated fonts without this padding, but was revised some time ago to include it.

>  
> How should we deal with this? Three options I can see: amending WOFF spec to allow up to 3 bytes of padding after last table, ask WOFF creation tools to reject files with extra padding (I do not know how many fonts will actually be affected) or adjust total unpacked length in WOFF header to exclude extra padding from original file length (although unpacking this will not result in original font file).

I think, based on what appears to be the common practice, that we should consider this last-table padding to be standard in sfnt files.

Regarding what the OpenType spec says: pay attention to the statement immediately before the sentence you cited from the "OpenType Font File" section, which reads:

    "Note: This function [i.e. the checksum-calculating code given in the spec to exemplify how checksums in the table directory are computed] implies that the length of a table must be a multiple of four bytes. In fact, a font is not considered structurally proper without the correct padding."

This seems to say that *every* table, as stored in the sfnt file, must be a multiple of 4 bytes in length, so that the checksum calculation function as defined in the spec can be applied to it.

There are a couple of other statements that also lend support to this interpretation. The "Recommendations" section (http://www.microsoft.com/typography/otspec/recom.htm) says that:

    "Any extra space after a table (and before the next LONG word boundry [sic]) should be padded with zeros."

It's certainly possible to read this as referring only to inter-table padding, but it would also be possible to read it as referring to every table, including the last.

And the specification for the 'head' table, checkSumAdjustment field, tells us:

    "To compute: set it to 0, sum the entire font as ULONG, ...."

which is a somewhat ill-defined operation unless the entire font is expected to be a multiple of 4 bytes in length - which in turn implies that the last table is padded as necessary to ensure 4-byte alignment.

Finally, the sfnt2woff tool I created while we were developing the spec will issue a warning if the last table is not padded in this way. It will still generate a .woff file, but gives a warning because decoding back to sfnt will not produce an exact copy of the original. I don't recall seeing any complaints or questions about this warning, which leads me to think that fonts with an unpadded final table are not widespread.

JK

Received on Tuesday, 8 June 2010 23:38:28 UTC