

WOFF 2 – Next-generation web font format - tosh
https://gist.github.com/sergejmueller/cf6b4f2133bcb3e2f64a

======
mmastrac

       > Of course you can use WOFF2 as a Base64 encoded string:
       >    ...
       >        url('data:font/woff2;base64,...') format('woff2'),
       >        url('data:font/woff;base64,...') format('woff');
    

Please, pretty please don't Base64 the WOFF and WOFF2 fonts in the same file.
That's basically just _inflating_ your font size by a guaranteed 80% or so. A
browser supporting WOFF2 is guaranteed to support WOFF!

I'd honestly recommend waiting until WOFF2 support is better before you use
them at all unless you have server-side support detection. In a year or so
it'll make sense. Now? Not so much. [1]

I do believe you should base64 encode your WOFF fonts and link the others. In
fact, I wrote a tool for that (if you are pulling fonts from Google's or some
other service). [2]

[1] [http://caniuse.com/#feat=woff2](http://caniuse.com/#feat=woff2)

[2] [https://github.com/mmastrac/webfont-
dl](https://github.com/mmastrac/webfont-dl)

~~~
currysausage
In a nutshell, this guy explains that the benefit of WOFF2 is that its
"compression format offers a 30% average gain over WOFF 1.0", only to go on
and demonstrate how to embed both WOFF1 _and_ WOFF2 as _data:_ URLs in the
same CSS?

Major facepalm.

------
scrollaway
> Think about the correct mime type for WOFF 2.0 files (Google uses
> font/woff2. W3C recommends application/font-woff2):

Heh. I'm very annoyed there is no official MIME registry for font/. fonts and
archive formats abuse the application/ registry. In decades now this hasn't
changed. Pretty annoying. Maybe this will be a needed push?

~~~
gsnedders
There was a discussion about this on the IETF lists a while ago — in short,
there's so much impetus against new top-level types that it's unlikely to ever
happen, seemingly, and that the application type was the appropriate place for
fonts to go. See the thread starting at [https://www.ietf.org/mail-
archive/web/apps-discuss/current/m...](https://www.ietf.org/mail-
archive/web/apps-discuss/current/msg03447.html).

It's been the status quo for a long time now — and existing implementations
are basically irrelevant (all browsers just sniff and totally ignore any type
because of this mess).

~~~
scrollaway
Fascinating, thanks!

------
m_eiman
So... Silly question, perhaps, but how is it possible that we need to replace
WOFF already? Didn't we have TTF and OTF for decodes without needing
replacement, and now we need to replace WOFF before it's even used a whole
lot? What did the WOFF designers miss?

~~~
jahewson
WOFF is simply gzip plus a header. This works well for OTF fonts where the
format is already heavily optimised for low size. However TTF files don't
compress as well, particularly the 'glyf' table whic contains the outlines and
typically accounts for a large percentage of the file size. WOFF 2 adds a
preprocessing stage which rewrites the glyf table into a more compact format
prior to gzipping.

~~~
robryk
Also, WOFF2 uses brotli instead of deflate.

