Meet WOFF, The Standard Web Font Format


On April 8, 2010, Mozilla, Opera and Microsoft submitted the WOFF File Format 1.0 specification to the W3C. The submission was published on Monday, April 19 at http://www.w3.org/Submission/2010/03/.

Browser vendors and a growing number of type foundries now agree on a common encoding format for web fonts, thus closing an era of cross-browser incompatibility that began when IE4 and Netscape 4 first added support for downloadable fonts in 1997.

At the time, both Microsoft and Netscape implemented incompatible proprietary solutions. Netscape supported and later dropped Bitstream’s Portable Font Resource (PFR) format.  Internet Explorer’s Embedded Open Type (EOT) supported the sub-setting and compression of fonts, as well as the definition of the origin policy for the font resource within the EOT file itself. Some font vendors have licensed their fonts for web use under EOT.

Ten years later, Apple added support for raw font linking to WebKit and Safari, allowing web authors to refer to raw TrueType or OpenType font files from their CSS stylesheets. Firefox and Opera followed but use of the feature was in practice limited to free fonts and specialist font obfuscation services like Typekit as font vendors were extremely reluctant to allow their intellectual property to be posted as-is on web servers. The typically large size of font files and the challenges involved in compressing HTTP responses for all users added practical challenges.

In March 2008, Microsoft submitted EOT for standardization to the W3C. Despite a large existing EOT-compatible IE installed base, a number of issues prevented consensus from emerging on the suitability of Microsoft’s format as a web font standard. At the W3C’s Technical Plenary that year, Microsoft indicated that a solution type foundries were comfortable with was essential to maximize author choice. In the summer of last year, such a solution emerged from a proposal by type designers Tal Leming and Erik van Blokland and Mozilla’s Jonathan Kew. The Web Open Font Format (WOFF) – an open, compressed encoding for sfnt-based font resources – was born.

The new format’s specification is a deliverable of the newly chartered Fonts Working Group on which browser vendors, type foundries and designers are represented. We are excited by some of the initial feedback to this announcement and look forward to contributing to the Working Group to advance the state of web font interoperability.

Sylvain Galineau
Program Manger

Update 5:25pm: small edits for clarity in the third paragraph.

Comments (22)

  1. Anonymous says:

    If this submission stays basically the same and doesn’t make extensive additions to the appendices (or other places), and this format is going to be used by authors, I think this is something you guys could be proud of supporting.

    In short: Sounds awesome, guys. Don’t mess it up.

  2. Anonymous says:

    If this submission stays basically the same and doesn’t make extensive additions to the appendices (or other places), and this format is going to be used by authors, I think this is something you guys could be proud of supporting.

    In short: Sounds awesome, guys. Don’t mess it up.

  3. Anonymous says:

    Hooray for Mozilla! And kudos to the Microsoft for getting behind this effort

  4. Anonymous says:

    I love this bit of MS spindoctoring –

    "Despite a large existing EOT-compatible IE installed base, a number of issues prevented consensus from emerging on the suitability of Microsoft’s format as a web font standard."

    In other words – the W3C bitch-slapped MS back to the dark ages.

  5. Grah says:

    If this submission stays basically the same and doesn’t make extensive additions to the appendices (or other places), and this format is going to be used by authors, I think this is something you guys could be proud of supporting.

    In short: Sounds awesome, guys. Don’t mess it up.

  6. Wurst says:

    I hope the web is ready for downloadable fonts and we won’t see too many garbage fonts filling our caches.

    Also, let’s keep our fingers crossed that people having a browser without downloadable-font support or having it disabled won’t see mojibake (it happened past, specifically in the dark times of over-90% IE prevalence).

  7. sroussey@network54.com says:

    Let’s hope not every web page looks like 1984 when people first used MacWrite!

  8. Jon R says:

    Hooray for Mozilla! And kudos to the Microsoft for getting behind this effort.

  9. Waffles offering fun…oh I mean good stuff! I’ve tested a few interesting fonts on Version 2.9 of my site and it’ll be interesting to see how IE9’s GPU support handles really complex fonts that so far have crippled the performance of every browser I’ve had tested the scenario with which was about half a year ago.

  10. Victor says:

    can’t wait to see this one on platform preview…

  11. hAl says:

    Does WOFF provide the same small size font files that are possible with EOT (combining font subsets and compression).

  12. boen_robot says:

    While there’s no indication if the next IE9 build will support WOFF, the very fact that you’re posting about WOFF on your blog makes me think it will be supported.

    Please IE team, don’t prove me wrong ^_^ .

  13. kl says:

    Foundries should just grow up. Those layers of obfuscation don’t protect fonts the least, because nobody even bothers to download them from pages, when all their fonts are available on PirateBay nicely packaged without DRM.

    Making web authors life harder and adding more odd formats won’t change that the least.

    Music industry dragged us through numerous "PlaysForSure" failures before they learned their lesson. Do we really have to repeat all that pain with fonts?

  14. Chris Lilley says:

    @Grah good point and the working group charter has specific language in place to avoid it. Changes based on implementation experience are ok, radical redesign for no reason is right out.

    @Wurst mojibake is typically a result of fonts being applied to ascii text to make it ‘look like’ soome other language. That won’t happen with WOFF, which is Unicode based. If the browser does not support font downloading or does not support WOFF, you will see platform font fallback for the right characters (or a ‘missing glyph’).

    @kl WOFF does not have DRM.

    @hAl yes, you can do subsetting and yes, WOFF has compression.

  15. TheCycoONE says:

    @hal: WOFF provides compression.  I’m not sure what you mean by subtypes, but the spec essentially says it’s TrueType or OpenType + metadata compressed.

  16. hAl says:

    @Stephen

    With EOT format that Micrsoft has been using since 1998 the font file consists of a subset of an OpenType fontset. The subset could be tailored to the website and contain a minimal amount of font characters thus making very small font files.

    If for instance you would want your name only in a scriptlike font it would only take 12-13 characters in the compressed EOT file and not the entire OpenType scriptlike fontfile.

  17. SC says:

    HORRAY! This is one of the biggest announcements on the web in the past 10 years. FINALLY!!!!

  18. steve_web says:

    Standards FTW! Awesome that everyone is working together on this.

  19. tom says:

    Awesome that everyone is

    working together on this.

  20. Sumit Pranav says:

    A good step towards standardization.

  21. Curious says:

    Would it be possible to maliciously craft a font file so that when it’s downloaded and used it causes a buffer overrun and potentially allow escalated privileges?  Didn’t this happen to Mozilla a few months back?

    What steps are MS taking to prevent this, if it is possible?

  22. Paul McKeown says:

    Thank you, Microsoft.  Genuinely appreciated.  This will provide a straightforward technical solution to one of the most common of end-user request.  5 gold stars from me. May I buy a beer sometime for whoever it was in MS got behind this?