WOFF 2.0: What is it, why is it coming, and what's next?

WOFF 2.0 is working its way towards being a standard recommended by the W3C, so it seems like a good time to look at the WOFF format and where it’s headed.

The Web Open Font Format (WOFF) is a font wrapper format designed to cut font sizes for quicker loading over the internet and lower bandwidth use. It reduces file sizes by on average 40-45%.

The only difference between WOFF and OpenType is that it uses zlib compression on each table and has a slightly different table directory and header. This means, like OpenType, it can contain both Type 1 and TrueType outlines.

I wrote about wrapper and outline formats last time, so if you’re not sure what I’m talking about it might be worth a look!

Why is WOFF 2.0 necessary?

When Adobe joined Microsoft to make OpenType in the 90s, it was CFF – a more space efficient version of Type 1 – which they chose to make part of the specification. This, combined with Type 1’s support of subroutines in glyph descriptions, means that CFF based fonts are generally 20-50% smaller than similar TrueType based fonts.

Considering the ‘CFF ‘ table is essentially a complete font compared to just the outlines (and some hinting data) provided by ‘glyf’ and ‘loca’, it’s pretty clear that TrueType outlines are bigger than is necessary. Some of this is due to their use of quadratic as opposed to cubic Bézier curves, but mostly it’s just not a space efficient design.

How does WOFF 2.0 solve this problem?

WOFF 2.0 introduces a pre-processing step which rearranges the data in the ‘glyf’ and ‘loca’ tables. The W3C have based this on the MicroType Express font compression format created by Monotype. This makes a range of improvements based on removing unnecessary data, using lengths instead of offsets, and variable length number encoding.

WOFF 2.0 sees on average a 27% improvement in file size reduction on TrueType fonts – about 12% more of an improvement than it shows on CFF fonts.

What else does WOFF 2.0 do to improve on WOFF 1.0?

Firstly, WOFF 2.0 compresses all the tables together and not individually. This reduces file sizes up to 2%.

It also uses the new Brotli compression scheme being developed by Google in Switzerland. These two changes are the only ones to affect CFF fonts, which have seen an average 15% reduction in size, so Brotli seems to make notable improvements on zlib.

What else could be improved in future versions of WOFF?

As far as I can see, the obvious place to try to make future improvements is actually by adding a pre-processing step to the CFF table too.

The glyph descriptions themselves are already relatively compact, but I’d be interested to see whether Huffman encoding could improve them. There’s a lot of offset data which could be either converted to lists of length stored in variable length numbers, or eliminated by stricter enforcement of ordering.

There’s even some data which is effectively useless. For example, in the 4-byte header at the start of the table, there is a field for ‘headerSize’ which is always 4, and ‘offSize’, which states the number of bytes used to define offsets which are relative to the start of the table. Unfortunately, all possible offsets like this are stored in DICT structures which use variable length number encoding anyway, so it has no use whatsoever.

Of course, it’s possible that these ideas would offer no real improvement, since pre-processing the data may make it so that Brotli can give much less of an improvement. Still, that’s why the W3C performs extensive evaluation of ideas and makes reports with its findings.

When can I use WOFF 2.0?

Now! Despite the fact it’s yet to reach W3C recommendation status, WOFF 2.0 is available in Chrome, Opera, Android browser, and you can activate it in Firefox with a flag. As is often the case with web standards, it’s available for use before it’s even finished!