Context: rev 2.0 of the Web font standard was going to use LZMA, it had issues (IP, decoding speed, clear spec for independent implementations), so Google propo

Context: rev 2.0 of the Web font standard was going to use LZMA, it had issues (IP, decoding speed, clear spec for independent implementations), so Google proposed a new format. WOFF report on Brotli: http://www.w3.org/TR/WOFF20ER/#candidateb http://www.w3.org/TR/WOFF20ER/#candidateb (and #candidatea says what they thought of LZMA) Reference code: https://code.google.com/p/font-compression-reference/ https://code.google.com/p/font-compression-reference/ (this aims for very slow but good compression, like their zopfli zlib encoder) Google's presentation: https://docs.google.com/presentation/d/1aigINmRR7fw_ml8rz0rJ3NTv08Qb3n6lZ_qvmxo8CzQ/present https://docs.google.com/presentation/d/1aigINmRR7fw_ml8rz0rJ... To the authors, I suspect it was a feature that it's 'just' DEFLATE with 4MB windows + more context for entropy encoding + tuned-up coding + a static dictionary + some other stuff--the WOFF spec mentions similarty to DEFLATE as a benefit, and they would like to keep it easy enough to for others to write decoders. I kind of wonder if it was derived from something Google had been using internally. If you decode the static dictionary in the spec, it has a bunch of words and phrases from the most-used languages as you'd expect, but also some things that look like common code fragments from Web pages, which would be right down Google's alley. And that's not stuff you need for font compression in particular.