WOFF File Format 1.0

W3C Recommendation 13 December 2012

This version:

http://www.w3.org/TR/2012/REC-WOFF-20121213/

Latest version:

http://www.w3.org/TR/WOFF/

Previous version:

http://www.w3.org/TR/2012/PR-WOFF-20121011/

Authors:

Jonathan Kew (Mozilla Corporation)

Tal Leming (Type Supply)

Erik van Blokland (LettError)

Please refer to theerrata for this document, which may include some normative corrections.

See alsotranslations.

Copyright © 2012W3C^® (MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademark anddocument use rules apply.

Abstract

This document specifies the WOFF font packaging format.This format was designed to provide lightweight, easy-to-implement compression of font data,suitable for use with CSS@font-face rules.Any properly licensed TrueType/OpenType/Open Font Format file can be packaged in WOFF format for Web use.User agents decode the WOFF file to restore the font data such that it will display identically to the input font.

The WOFF format also allows additional metadata to be attached to the file;this can be used by font designers or vendors to include licensing or other information,beyond that present in the original font.Such metadata does not affect the rendering of the font in any way,but may be displayed to the user on request.

The WOFF format is not intended to replace other formatssuch as TrueType/OpenType/Open Font Format or SVG fonts,but provides an alternative solution for use cases where these formats may be less optimal,or where licensing considerations make their use less acceptable.

Status of This Document

This section describes the status of this document at thetime of its publication. Other documents may supersede thisdocument. A list of current W3C publications and the latestrevision of this technical report can be found in theW3C technical reports index athttp://www.w3.org/TR/.

This is the W3C Recommendation of "WOFF File Format 1.0". This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

Please send comments about this document towww-font@w3.org (withpublic archive).

This specification has been edited, relative to the11 October 2011 Proposed Recommendation, to incorporate minor changes to the Internet Media Type registration, as a result of IANA expert review. There is achanges appendix describing the changes made.

The CR exit criteria were:

1. Sufficient reports of implementation experience have been gathered to demonstrate that the “WOFF File Format 1.0” syntax and features are implementable and are interpreted in a consistent manner. To do so, the Working Group would insure that all features have been implemented in at least two implementation in an interoperable way.
2. The implementations have been developed independently.

The Working Group has developed public test suites as follows:

• User Agent tests

• Authoring Tool tests

• Test data forthe file format itself

AWOFF validator was developed, to make all the file format checks indicated in the specification. The validator passes 100% of these tests. The new W3C Test Harness was used to deploy the tests:Authoring Tools test harness andUser Agent test harness.

TheUser Agents implementation report andAuthoring Tools implementation report are available.

This document was initially developed by contributors to thewww-font@w3.org mailing list. After trial implementation, it became theWOFF Submission and was further developed by theWebFonts Working Group at W3C.

This document was produced by a group operating under the5February 2004 W3C Patent Policy.W3C maintains apublic listof any patent disclosures made in connection with thedeliverables of the group; that page also includes instructions for disclosing a patent.An individual who has actual knowledge of a patent which theindividual believes containsEssential Claim(s) must disclose theinformation in accordance withsection 6 of the W3C Patent Policy.

Table of Contents

1. Introduction
2. General Requirements
3. Overall File Structure
4. WOFF Header
5. Table Directory
6. Font Data Tables
7. Extended Metadata Block
8. Private Data Block

Appendix A: Extended Metadata Examples
Appendix B: Media Type Registration
Appendix C: Changes
References

1. Introduction

This document specifies a simple compressed file format for fonts, designedprimarily for use on the Web and known as WOFF (Web Open Font Format).Despite this name, WOFF should be regarded as a container formator "wrapper" for font data in already-existing formatsrather than an actual font format in its own right.

The WOFF format is a container for the table-based sfnt structure used in e.g. TrueType [TrueType], OpenType [OpenType] and Open Font Format [OFF] fonts, hereafter referred to as sfnt fonts. A WOFF file is simply a repackagedversion of a sfnt font with optional compression of the font data tables.The WOFF file format also allows font metadata and private-use data to beincluded separately from the font data. WOFF encoding tools convert an inputsfnt font into a WOFF formatted file, and user agents restore thesfnt font data for use with a Web document.

The structure and contents of decoded font data exactly matchthose of a well-formed input font file. Tools producing WOFF files may provide otherfont editing features such as glyph subsetting, validation or font featureadditions but these are considered outside the scope of this format. Independentof these features, both tools and user agents are expected to assure that the validity ofthe underlying font data is preserved.

Notational Conventions

The all-uppercase key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to beinterpreted as described in RFC 2119 [RFC-2119].If these words occur in lower- or mixed case, they should be interpretedin accordance with their normal English meaning.

This document includes sections of text that are called out as "Notes"and set off from the main text of the specification.These notes are intended as informative explanations or clarifications,to serve as hints or guides to implementers and users,but are not part of the normative text.

2. General Requirements

The primary purpose of the WOFF format is to package fonts linked to Web documentsby means of CSS@font-face rules.User agents supporting the WOFF file format for linked fonts must respectthe requirements of the CSS3 Fonts specification ([CSS3-Fonts]Section 4.1:The @font-face rule). In particular,such linked fonts are only available to the documents that reference them;they MUST NOT be made available to other applications or documents on the user's system.

3. Overall File Structure

The structure of WOFF files is similar to the structure of sfnt fonts:a table directory containing lengths and offsets to individual font data tables,followed by the data tables themselves. The sfnt structure is described fully inthe TrueType [TrueType], OpenType [OpenType] and Open Font Format [OFF] specifications.

The main body of the file consists of the same collection of font data tablesas the input sfnt font, stored in the same order, exceptthateach table MAY be compressed, and the sfnt table directory is replaced bythe WOFF table directory.

A complete WOFF file consists of several blocks: a 44-byte header,immediately followed (in this order) by a variable-size table directory,a variable number of font tables, an optional block of extendedmetadata, and an optional block of private data.Except for padding with a maximum of three null bytesin places where 4-byte alignment of a table lengthor block offset is specified,there MUST NOT be any extraneous data between the data blocksor font data tables indicated by the WOFF header and table directory,or beyond the last such block or table.If such extraneous data is presenta conforming user agentMUST reject the file as invalid.The fileMUST also be rejected as invalidif the offsets and lengths of any data blocks or font tablesindicate overlapping byte ranges of the file,or ranges that would extend beyond the end of the file.

Data values stored in the WOFF Header and WOFF Table Directory sections arestored in big-endian format, just as values are within sfnt fonts. Thefollowing basic data types are used in the description:

All sizes and offsets described in this document are assumed to be in bytes unlessotherwise noted.

4. WOFF Header

The header includes an identifying signature and indicates the specific kindof font data included in the file (TrueType or CFF outline data); it also has afont version number, offsets to additional data chunks, and the number ofentries in the table directory that immediately follows the header:

Thesignature field in the WOFF headerMUST contain the "magic number" 0x774F4646.If the field does not contain this value,user agents MUST reject the file as invalid.

Theflavor field corresponds to the "sfnt version"field found at the beginning of an sfnt file,indicating the type of font data contained.Although only fonts of type 0x00010000 (the version number 1.0as a 16.16 fixed-point value, indicating TrueType glyph data)and 0x4F54544F (the tag'OTTO', indicating CFF glyph data)are widely supported at present, it is not an error in the WOFF file if theflavor field contains a different value, indicating aWOFF-packaged version of a different sfnt flavor. (The value 0x74727565'true'has been used for some TrueType-flavored fonts on MacOS, for example.) Whether client software will actually support other types ofsfnt font data is outside the scope of the WOFF specification, whichsimply describes how the sfnt is repackaged for Web use.

The WOFFmajorVersion andminorVersion fields specify the version number for a givenWOFF file, which can be based on the version number of the input font but isnot required to be. These fields have no effect on font loading or usagebehavior in user agents.

ThetotalSfntSize field is the sum of theuncompressed font table sizes, each padded to a multiple of 4 bytes, plusthe size of the sfnt header and table directory. Thus, this is the size ofbuffer needed to decode the complete WOFF-packaged font (but not metadata,which is not part of the input sfnt file) into a standard sfnt structure.This value MUST be a multiple of 4, because all font tablesincluding the last are to be padded to a 4-byte boundary.If this valueis incorrect, a conforming user agent MUST reject the file as invalid.

The sfnt header includes three fields (searchRange,entrySelector andrangeShift) that are designed tofacilitate a binary search of the table directory.As the proper value for each of these fields can be computed directlyfrom the number of font tables, they are not stored in the WOFF file.User agents that decode WOFF files back to an sfnt structureMUST therefore compute the correct values for these fields in the sfnt header,as described in the OpenType/OFF specification.[OFF]

totalSfntSize = 12 // size of sfnt header ("offset table" in the OpenType spec)totalSfntSize += 16 * numTables // size of table record (directory of font tables)for each table:    totalSfntSize += (table.origLength + 3) & 0xFFFFFFFC // table size, padded

If either or both of the metadata or private blocks is not present,the relevant offset and length fields MUST be set to zero.If the metadata or private data offset and length fields indicate byteranges that overlap other data blocks or tables,or extend beyond the end of the file,a conforming user agent MUST reject the file as invalid.

The header includes areserved field; this MUST beset to zero.If this field is non-zero, a conforming user agentMUST reject the file as invalid.

5. Table Directory

The table directory is an array of WOFF table directory entries, as definedbelow. The directory follows immediately after the WOFF file header; therefore,there is no explicit offset in the header pointing to this block. Its size iscalculated by multiplying thenumTables value in theWOFF header times the size of a single WOFF table directory. Each tabledirectory entry specifies the size and location of a single font data table.

The format oftag values are defined by thespecifications for sfnt fonts. Theoffset andcompLength fields identify the location of thecompressed font table. TheorigLength andorigCheckSumfields are the length and checksum of theinput font table from the table directory of the inputfont.

The sfnt format specifications require that font tables be aligned on4-byte boundaries. Font tables whose length is not a multiple of 4 are paddedwith null bytes up to the next 4-byte boundary.Font data tables in the WOFFfile have the same requirement: they MUST begin on 4-byte boundaries and bezero-padded to the next 4-byte boundary. ThecompLength andorigLength fieldsin the table directory store the exact, unpadded length.

If theoffset andcompLength valuesindicate a byte range that overlapsother data blocks or font tables, or if the byte range extends beyondthe end of the file,a conforming user agent MUST reject the file asinvalid.

If the length of a compressed font table would be the same as or greater thanthe length of the input font table, the font table MUST be storeduncompressed in the WOFF file and thecompLength setequal to theorigLength.Tools MAY also opt to leaveother tables uncompressed (e.g. all tables less than a certain size), in whichcasecompLength will be equal toorigLength for these tables as well.WOFF files containingtable directory entries for whichcompLength isgreater thanorigLength are considered invalid andMUST NOT be loaded by user agents.Files containing compressed font tables thatdecompress to a size other thanorigLength are alsoconsidered invalid and MUST NOT be loaded.

The sfnt font specifications require that table directory entriesare sorted in ascending order oftag value. Tosimplify processing,WOFF-producing tools MUST produce a table directory withentries in ascendingtag value order.User agents MUSTlikewise assure that the sfnt table directory is recreated in ascendingtag order when restoring the font data to its uncompressedstate. The ordering of the font tables themselves is independent of the order ofdirectory entries, as described below.

sfnt fonts store a checksum for each table in the table directory, andan overall checksum for the entire font in theheadtable (see the TrueType, OpenType or Open Font Format specifications for thedefinition of each calculation).Tools producing WOFF files MUST validate thesechecksums, and reject the font if errors are found.

A WOFF file contains the same set of font tables as the input fontfrom which it was created. This means that the overall font checksum of afont decompressed from a conformant WOFF file will always match the checksumin the well-formed input font. In the case where theinput font included unreferenced data between or after the actual tables,this would affect the overall checksum of the input font, but would bedropped during creation of the WOFF file.

A well-formed input font does not have structural anomalies such asincorrect padding, overlapping font tables, extraneous data between tables (which will be discarded by the WOFFgenerator), or incorrect checksums.

To ensure that lossless round-trip conversion from sfnt to WOFF and backwill be possible, a well-formed input font should conformto certain norms that are notstrictly required by the OpenType/OFF specification, although they are commonpractice:

Font table padding

The OpenType/OFF specification is not entirely clear about whetheralltables in an sfnt font must be padded with 0-3 zero bytes to a multipleof 4 bytes in length, or whether this applies onlybetween tables,and the final table of the file may be left unpadded.Most current tools and fonts seem to expect all tables to be padded to a 4-byteboundary, including the last.The WOFF specification assumes this behavior, and specifies that thetotalSfntLength field in the WOFF header provides for such padding.To ensure that a given font can be packaged as a WOFF file and then decodedto its original format and give a byte-for-byte identical result,the input font should therefore be padded to a multiple of 4 bytes in length.

No "hidden" data

The OpenType/OFF specification does not explicitly prohibit thepresence of "extra" data or padding in between the font tables;as the table directory includes the offset and length of each actual table,such data would simply be ignored. However, the WOFF format makes noprovision to preserve such non-font-table data when packaging a font,and therefore it would not survive a round-trip format conversion.

Header fields are correct

The OpenType/OFF header fields (searchRange,entrySelector,rangeShift)that are designed to facilitate a binary search of the table directorymust be correct in the input sfnt file,as the WOFF format does not directly preserve these fieldsbut assumes a WOFF decoder will recompute them as needed.

Checksums are correct

The WOFF specification says that table checksums must be validated(and corrected if necessary) by WOFF creators.In order for completeround-trip fidelity, therefore, the checksums in the input sfnt filemust also be correct prior to WOFF packaging.

No overlapping tables

The offset and length values in the input sfnt table directory must not indicate overlapping byte ranges of the input font.

The result of creating a WOFF file and then decoding this toregenerate an sfnt font MUST result in a final font that is bitwise-identical tothe well-formed input font..If the input font has defects or anomaliesthat make this impossible,the WOFF-generating tool SHOULD either reject the fontor issue an appropriate warningthat lossless round-trip conversion will not be possible.

6. Font Data Tables

The font data tables in the WOFF file are exactly the same as the tables inthe input font, except thateach table MAY have beencompressed. If compressed,it MUST have been compressed by thecompress2() function of zlib [Compress2] (or anequivalent, compatible algorithm). User agents use theuncompress() function of zlib [Uncompress](or anequivalent, compatible algorithm) to decompress each table.The underlying format these functions use is described in the ZLIBspecification [ZLib].User agents or other programs that decode WOFF files MUST be able to handletables that have been compressed.If thedecompression function fails for any table, the WOFF file is invalidand MUST NOT be loaded.

The font data tables MUST be stored immediately following the tabledirectory, without gaps except for any padding that is required (up to threenull bytes at the end of each table) to ensure 4-byte alignment.

Font tables in WOFF files MUST be stored in the same order as the well-formed input font.The table order is implied byoffset values in the table directory; sorting tabledirectory entries into ascendingoffset value orderproduces a list of entries in an order equivalent to that of the font tables.

7. Extended Metadata Block

The WOFF file MAY include a block of extended metadata. This may be more extensive and more easily accesible than metadata present in sfnt tables. The metadata block consists of XML data compressed byzlib; the file header specifies both the size of the actual compressed and theoriginal uncompressed size in order to facilitate memory allocation.

The presence (or absence) and content of the metadata blockMUST NOT affect font loading or rendering behavior of user agents;it is intended to be purely informative.User agents MAY provide a means for users to view information about fonts(such as a "Font Information" panel).If such information is provided,then they MUST treat the metadata block as the primary source,and MAY fall back to presenting information from the font'snametable entries when relevant extended metadata elements are not present.

If present, the metadata MUST be compressed; it is never stored inuncompressed form.

The metadata block MUST follow immediately after the last font table. As all fontdata tables are padded with up to three null bytesif needed to reach a 4-byte boundary,the beginning of the metadata block will always be 4-byte aligned.If the metadata block is the last block in the WOFF file,there SHOULD be no additional padding after the end of the block.

The extended metadata MUST be well-formed XMLencoded in UTF-8.

The schema for the extended metadata XML is described below.If the extended metadata does not match this schema,it is invalid.It is also invalid if it cannot be decompressedby zlib'suncompress() function (or equivalent),or if the length of the decompressed data does not match themetaOrigLength value specified in the WOFF header.Thus, valid metadata is well formed, conforms to the schema below,and is stored in compressed form in the WOFF file.A conforming user agent MUST ignore an invalid metadata block,as if the block were not present.

This description is also availableas a RelaxNG schema.In the event of a discrepancy between the RelaxNG schemaand the text of the specification, the text takes precedence.

Several elements store their data intextchild elements; this is to support localization.Thetextelements MAY be given alang attributein the XML namespace [XML].For backwards compatibility,lang attributes in the default namepsaceare also accepted in older content, and SHOULD be treated the sameasxml:lang.New content SHOULD instead usexml:lang.

The syntax of values of thexml:lang attribute can be found inBCP47 [BCP47].A user agent displaying metadata SHOULD choose a preferred language/locale to display from among those available, following BCP47.

The user agent SHOULD choose which of the availabletextelements to display as follows:

1. If atext element is available that matches the user'spreferred language, as determined viaan explicit preference or implied by the current locale, use this language.
2. If the user agent has a concept of a list of "acceptable" languages ordefaults, try each of these in turn and use the first one for which a match found.
3. If there is atext element with noxml:langattribute, use this; in the event that more than one exists, use the first of them.
4. If no match is found yet, use the firsttext element.(Thus, the metadata creator can determine the "localization of last resort"simply by choosing which language to put first in each group oftext elements.)

Such localizable elements areindicated by the statement"This element may be localized usingtext child elements"in the description below;the internal structure oftext elements withxml:lang attributes is not repeated for each elementtype.In each of these localizable elements,at least onetext child element MUST be present,except in the case of thelicense element (as described below).

metadata element

The main element.This element is REQUIRED.

attributes
version	A version number indicating the format version of themetadata element. This is currently1.0.This attribute is REQUIRED.
children
uniqueid	Zero or one child elements
vendor	Zero or one child elements
credits	Zero or one child elements
description	Zero or one child elements
license	Zero or one child elements
copyright	Zero or one child elements
trademark	Zero or one child elements
licensee	Zero or one child elements
extension	Zero or more child elements

All first-level child elements of the metadata are OPTIONAL, and may occur inany order as children of the top-levelmetadataelement.

Theextension element is intended to allowvendors to include metadata that is not covered by the specific elementsdefined here, while following a standard model.User agents that provide a meansfor the user to view WOFF file metadata SHOULD include suchextension elements in the metadata presented to the user.

uniqueid element

A unique identifier string for the font. This element is recommended, but notrequired for the metadata to be valid. This element MUST be a child of themetadata element. This is an empty element.

attributes
id	The identification string.This attribute is REQUIRED.

The string defined in theuniqueid element is notguaranteed to be truly unique, as there is no central registry or authority toensure this, but it is intended to allow vendors to reliably identify the exactversion of a particular font. The use of "reverse-DNS" prefixes to provide a"namespace" is recommended; this can be augmented by additional identificationdata of the vendor's own design.

Theid attribute of theuniqueid element,and of several further metadata elements defined below,is not required to conform to the rules for the XML type ID;its form is at the discretion of the font creator or vendor.

vendor element

Information about the font vendor. This element is recommended, but notrequired for the metadata to be valid. This element MUST be a child of themetadata element. This is an empty element.

attributes
name	The name of the font vendor.This attribute is REQUIRED.
url	The url for the font vendor. This attribute isOPTIONAL.
dir	The text direction, eitherltr (for "left to right") orrtl (for "right to left").This attribute is OPTIONAL and, if omitted, defaults toltr.
class	An arbitrary set of space-separated tokens.This attribute is OPTIONAL.

credits element

Credit information for the font. This can include any type of credit thevendor desires: designer, hinter, and so on. This element is OPTIONAL. Ifpresent, it MUST be a child of themetadata elementand it MUST contain at least onecredit element. Thiselement has no attributes.

children
credit	One or more child elements

credit element

A single credit record. If present, it MUST be a child of thecredits element. This is an empty element.

attributes
name	The name of the entity being credited.This attribute is REQUIRED.
url	The url for the entity being credited. This attribute isOPTIONAL.
role	The role of the entity being credited. This attribute isOPTIONAL.
dir	The text direction, eitherltr (for "left to right") orrtl (for "right to left").This attribute is OPTIONAL and, if omitted, defaults toltr.
class	An arbitrary set of space-separated tokens.This attribute is OPTIONAL.

description element

An arbitrary text description of the font's design, its history, etc. Thiselement is OPTIONAL. If present, it MUST be a child of themetadata element.This element may be localized usingtext child elements.

attributes
url	The url for more information about the font design, history, etc. This attribute is OPTIONAL.
children
text	One or more child elements containing character data and optionallydiv and/orspan children

license element

Licensing information for the font.This element is OPTIONAL. If present, it MUST be achild of themetadata element.This element may be localized usingtext child elements;however, it is permitted to be empty (for example, if the vendorprefers to just provide a license URL rather than including the actualtext of the license.)

attributes
url	The url for the license, more information about the license,etc. This attribute is OPTIONAL.
id	An identifying string for the license. This attribute isOPTIONAL.
children
text	Zero or more child elements containing character data and optionallydiv and/orspan children

copyright element

The copyright for the font. This element is OPTIONAL. If present, it MUST bea child of themetadata element.This element may be localized usingtext child elements.This element has no attributes.

children
text	One or more child elements containing character data and optionallydiv and/orspan children

trademark element

The trademark for the font. This element is OPTIONAL. If present, it MUST bea child of themetadata element.This element may be localized usingtext child elements.This element has no attributes.

children
text	One or more child elements containing character data and optionallydiv and/orspan children

licensee element

The licensee of the font. This element is OPTIONAL. If present, it MUST be achild of themetadata element. This is an emptyelement.

attributes
name	The name of the licensee.This attribute is REQUIRED.
dir	The text direction, eitherltr (for "left to right") orrtl (for "right to left").This attribute is OPTIONAL and, if omitted, defaults toltr.
class	An arbitrary set of space-separated tokens.This attribute is OPTIONAL.

Although the metadata elements and structure defined aboveare expected to be sufficient for most needs,an extension mechanism is also provided so that font vendorscan include arbitrary metadata items that do not fitthe standard elements above:

extension element

A container element for extended metadata provided by the vendor. Zero or moreextension elements may be present as children ofthe top-levelmetadata element. Each suchmetadata extension has an optionalname,which may be provided in multiple languages,and one or moreitem elements.

attributes
id	An arbitrary identifier defined by the vendor.This attribute is OPTIONAL.
children
name	Zero or more child elements
item	One or more child elements

item element

At least oneitem element MUST be present ineachextension container.

attributes
id	An arbitrary identifier defined by the vendor.This attribute is OPTIONAL.
children
name	One or more child elements
value	One or more child elements

name element

Zero or morename elements may be used to providea human-friendly name for the collection of extended metadata itemsin anextension element.A user agentthat displays metadata SHOULD choose the name with most the appropriate languagefrom among those available for each namedextension element.This child element is OPTIONAL inextension elements;anonymous extension elements are also permissible.

One or morename elements are also used to providea human-friendly name for a specific extended metadata item. A user agentthat displays metadata SHOULD choose the name with the most appropriate language fromamong those available for eachitem element.This child element is REQUIRED initem elements;anitem element with noname is invalid and SHOULD be ignored.

attributes
xml:lang	A language tag as defined in BCP47 [BCP47].This attribute is OPTIONAL.
dir	The text direction, eitherltr (for "left to right") orrtl (for "right to left").This attribute is OPTIONAL and, if omitted, defaults toltr.
class	An arbitrary set of space-separated tokens.This attribute is OPTIONAL.

value element

One or morevalue elements are used to providethe value of a specific extended metadata item.A user agentthat displays metadata SHOULD choose the value with the most appropriate language fromamong those available for eachitem element.This child element is REQUIRED;anitem element with novalue is invalid and SHOULD be ignored.

attributes
xml:lang	A language tag as defined in BCP47 [BCP47].This attribute is OPTIONAL.
dir	The text direction, eitherltr (for "left to right") orrtl (for "right to left").This attribute is OPTIONAL and, if omitted, defaults toltr.
class	An arbitrary set of space-separated tokens.This attribute is OPTIONAL.

Wheretext elements are used to contain (localizable) content,further structure MAY also be providedusingdiv andspan child elementssimilar to those used in HTML.

text element

An element used to contain a particular localization of a metadata element's contents. This element has a mixed content model;in addition to the child elements mentioned below, it may directly contain character data.

attributes
xml:lang	A language tag (as specified in BCP47 [BCP47]) indicatingthe language of this particular version of the metadata element's content.This attribute is OPTIONAL; however, for multipletext childrenof a metadata element to be usefully distinguished,they SHOULD all be tagged with appropriate different language codes.
dir	The text direction, eitherltr (for "left to right") orrtl (for "right to left").This attribute is OPTIONAL and, if omitted, defaults toltr.
class	An arbitrary set of space-separated tokens.This attribute is OPTIONAL.
children
div	Contains a block of text, such as a paragraph or heading.
span	Contains an inline run of text.

div element

A block-level element used, for example, to contain a paragraph.

attributes
dir	The text direction, eitherltr (for "left to right") orrtl (for "right to left").This attribute is OPTIONAL and, if omitted, defaults toltr.
class	An arbitrary set of space-separated tokens.This attribute is OPTIONAL.

span element

An inline element used, for example, to indicate a run of textwith a different text direction, or in a different language.

attributes
dir	The text direction, eitherltr (for "left to right") orrtl (for "right to left").This attribute is OPTIONAL and, if omitted, defaults toltr.
class	An arbitrary set of space-separated tokens.This attribute is OPTIONAL.

Thetext elements used to hold(localizable) text for a number of the individual pieces of metadatathus have a mixed content model consisting of text content,div andspan elements;div elements have a mixed content model of text content,div andspan elements;andspan elements have a mixed content model of text contentandspan elements.In other words,div can contain otherdiv elements;span can contain otherspan elements;span does not require a containingdiv.

Appendix A includes several examplesof the content of the metadata block.

8. Private Data Block

The WOFF file MAY include a block of arbitrary data, allowing font creatorsto include whatever information they wish.The content of this data MUST NOTaffect font usage or load behavior of user agents.User agents should make no assumptionsabout the content of a private block; it may (for example) contain ASCII orUnicode text, or some vendor-defined binary data, and it may be compressed orencrypted, but it has no publicly defined format. Conformant user agents willnot assume anything about the structure of this data. Only the font developer orvendor responsible for the private block is expected to understand itscontents.

The private data block, if present, MUST be the last block in the WOFF file,following all the font tables and any extended metadata block.The private datablock MUST begin on a 4-byte boundary in the WOFF file, with up to three nullbytes inserted as padding after any preceding metadata blockif needed to ensure this.The end of the private data block MUST correspond to the end of the WOFF file.

Appendix A: Extended Metadata Examples

This appendix is purely informative, not a normative part of the WOFF specification.

This "dummy" metadata block illustrates the use of the metadata elementsdescribed in section 7, including the use of multipletextchild elements to provide localized versions of certain elements.

<?xml version="1.0" encoding="UTF-8"?><metadata version="1.0">    <uniqueid />    <vendor name="Font Vendor" url="http://fontvendor.example.com" />    <credits>        <credit            name="Font Designer"            url="http://fontdesigner.example.com"            role="Lead" />        <credit            name="Another Font Designer"            url="http://anotherdesigner.example.org"            role="Contributor" />        <credit            name="Yet Another"            role="Hinting" />    </credits>    <description>        <text xml:lang="en">            A member of the Demo font family.            This font is a humanist sans serif style designed            for optimal legibility in low-resolution environments.            It can be obtained from fontvendor.example.com.        </text>    </description>    <license url="http://fontvendor.example.com/license"            >        <text xml:lang="en">A license goes here.</text>        <text xml:lang="fr">Un permis va ici.</text>    </license>    <copyright>        <text xml:lang="en">Copyright ©2009 Font Vendor"</text>        <text xml:lang="ko">저작권 ©2009 Font Vendor"</text>    </copyright>    <trademark>        <text xml:lang="en">Demo Font is a trademark of Font Vendor</text>        <text xml:lang="fr">Demo Font est une marque déposée de Font Vendor</text>        <text xml:lang="de">Demo Font ist ein eingetragenes Warenzeichen der Font Vendor</text>        <text xml:lang="ja">Demo FontはFont Vendorの商標である</text>    </trademark>    <licensee name="Wonderful Websites, Inc." />    <extension>        <name xml:lang="en">Additional font information</name>        <name xml:lang="fr">L'information supplémentaire de fonte</name>        <item>            <name xml:lang="en">Purpose</name>            <name xml:lang="fr">But</name>            <value xml:lang="en">This font exists merely as an example of WOFF packaging.</value>            <value xml:lang="fr">Cette fonte existe simplement comme exemple de l'empaquetage de WOFF.</value>        </item>    </extension></metadata>

A real-life example of a simple metadata block(reproduced by permission of FSI FontShop International GmbH).

<?xml version="1.0" encoding="UTF-8"?><metadata version="1.0">   <uniqueid/>   <vendor name="FSI FontShop International GmbH" url="http://www.fontfont.com"/>   <credits>       <credit name="Steffen Sauerteig" role="design"/>       <credit name="Henning Wagenbreth" role="design"/>       <credit name="FSI FontShop International GmbH" url="http://www.fontfont.com" role="production"/>   </credits>   <description>       <text lang="en">A FontFont for the Web</text>   </description>   <license url="http://www.fontfont.com/support/licensing_web.ep">       <text lang="en">      FontFont Web license v 1.0.      For details see http://www.fontfont.com/eula/license_Webfonts_v_1_0.html    </text>   </license>   <copyright>       <text lang="en">2009 Henning Wagenbreth, Steffen Sauerteig published by FSI FontShop International GmbH</text>   </copyright>   <trademark>       <text lang="en">Prater is a trademark of FSI FontShop International GmbH</text>   </trademark></metadata>

Another example of a metadata block (reproduced by permission of Ascender Corporation).This is dynamically generated, with theuniqueid andlicensee elements modified to be unique for each customer.

<?xml version="1.0" encoding="UTF-8"?><metadata version="1.0"><uniqueid /><vendor name="Ascender Corp" url="http://www.fontslive.com" /><license url="http://www.fontslive.com/info/Web-fonts-eula.aspx"id="ascender-Webfonts-eula-v1"><text lang="en">This font software is the valuable property of AscenderCorporation and/or its suppliers and its use by you is covered under theterms of the Web Font license agreement between you and AscenderCorporation. You may ONLY use this font software with the licensed Web site.Except as specifically permitted by the license, you may not copy this fontsoftware. If you have any questions, please contact Ascender Corp.</text></license><licensee name="FontsLive.com" /></metadata>

Here is an example of how thediv element could be used,modified from a portion of theXML file for Gentium Pluswhich, when viewed as plain text, has paragraph formatting.

The original metadata file contained:

<description> <text lang="en">Gentium ("belonging to the nations" in Latin) is a Unicode typeface family designed to enable the many diverse ethnic groups around the world who use the Latin, Cyrillic and Greek scripts to produce readable, high-qualitypublications. The design is intended to be highly readable, reasonablycompact, and visually attractive. Gentium has won a "Certificate of Excellencein Typeface Design" in two major international typeface design competitions: bukva:raz! (2001), TDC2003 (2003).The Gentium Plus font family is based on the original design. It currently comes with regular and italic face only, although additional weights are indevelopment.The goal for this product is to provide a single Unicode-based font familythat contains a comprehensive inventory of glyphs needed for almost anyRoman- or Cyrillic-based writing system, whether used for phonetic ororthographic needs, and provide a matching Greek face. In addition, thereis provision for other characters and symbols useful to linguists. Thisfont makes use of state-of-the-art font technologies to support complextypographic issues, such as the need to position arbitrary combinationsof base glyphs and diacritics optimally.   (and so on) </text></description>

Using thediv element, this could become:

<description> <text xml:lang="en">   <div>Gentium ("belonging to the nations" in Latin) is a Unicode   typeface family designed to enable the many diverse ethnic groups   around the world who use the Latin, Cyrillic and Greek scripts to   produce readable, high-quality publications. The design is intended   to be highly readable, reasonably compact, and visually attractive.   Gentium has won a "Certificate of Excellence in Typeface   Design" in two major international typeface design   competitions: bukva:raz! (2001), TDC2003 (2003).</div>   <div>The Gentium Plus font family is based on the original design.   It currently comes with regular and italic face only, although   additional weights are in development.</div>   <div>The goal for this product is to provide a single Unicode-based   font family that contains a comprehensive inventory of glyphs   needed for almost any Roman- or Cyrillic-based writing system,   whether used for phonetic or orthographic needs, and provide a   matching Greek face. In addition, there is provision for other   characters and symbols useful to linguists. This font makes use of   state-of-the-art font technologies to support complex typographic   issues, such as the need to position arbitrary combinations of base   glyphs and diacritics optimally.</div>   (and so on) </text></description>

Appendix B: Media Type registration

This appendix registers a new MIME media type, in conformance withBCP 13 andW3CRegMedia.

Type name:

application

Subtype name:

font-woff

Required parameters:

None.

Optional parameters:

None.

Encoding considerations:

binary.

Security considerations:

Fonts are interpreted data structures that represent collections of glyph outlines, metrics and layout information for various languages and writing systems. Currently, there are many standardized font data tables that allow an unspecified number of entries, and where existing, predefined data fields allow storage of binary data with variable length. There is a significant risk that the flexibility of font data structures may be exploited to hide malicious binary content disguised as a font data component.

WOFF is based on the table-based SFNT (scalable font) format which is highly extensible and offers an opportunity to introduce additional data structures when needed. However, this same extensibility may present specific security concerns – the flexibility and ease of defining new data structures makes it easy for any arbitrary data to be added and hidden inside a font file.

WOFF fonts may contain 'hints' for the alignment of graphical elements of the glyphs with the target display pixel grid, and depending on the font technology utilized in the creation of a font these hints may represent active code interpreted and executed by the font rasterizer. Even though they operate within the confines of the glyph outline conversion system and have no access outside the font rendering machinery, hint instructions can be, however, quite complex, and a maliciously designed complex font could cause undue resource consumption (e.g. memory or CPU cycles) on a machine interpreting it. Indeed, fonts are sufficiently complex that most if not all interpreters cannot be completely protected from malicious fonts without undue performance penalties.

Widespread use of fonts as necessary component of visual content presentation warrants that a careful attention should be given to security considerations whenever a font is either embedded into an electronic document or transmitted alongside media content as a linked resource.

WOFF uses gzip compression. The WOFF header contains the uncompressed length of each compressed table. Applications may therefore constrain the size of memory buffer allocated for decompression and may stop writing if a maliciously crafted WOFF file in fact contains more data than is indicated.

WOFF does not provide privacy protections internally; if needed, these should be provided externally.

WOFF has a private data block facility, which may contain arbitrary binary data. WOFF does not provide a means to access this, or to execute any code contained therein. WOFFrequires that the content of this block not affect font rendering in any way.

Interoperability considerations:

Published specification:

This media type registration is extracted fromtheWOFF specification at W3C.

Applications that use this media type:

WOFF is used by Web browsers, often in conjunction with HTML and CSS.

Additional information:

Magic number(s):

The signature field in the WOFF header MUST contain the "magic number" 0x774F4646

File extension(s):

woff

Macintosh file type code(s):

(no code specified)

Macintosh Universal Type Identifier code:

org.w3c.woff

Fragment Identifiers

none.

Person & email address to contact for further information:

Chris Lilley (www-font@w3.org).

Intended usage:

COMMON

Restrictions on usage:

None

Author:

The WOFF specification is a work product of the World Wide Web Consortium's WebFonts Working Group.

Change controller:

The W3C has change control over this specification.

Appendix C: Changes

The following changes have been made, relative to the27 July 2010 First Public Working Draft. No new features have been added, except for optional enhancements to the metadata format; the remaining changes are clarifications and corrections to existing features.

• Clarified that WOFF is a fontpackaging or wrapper format, not a new font format as such.
• Clarified padding and byte-alignment requirements throughout
• Preferred the term 'input font' rather than 'original file' to describethe font which is converted to WOFF
• Clarified that any subsetting, checksum-correction, or DSIG invalidating changesprior to WOFF conversion are out of scope for the WOFF specification.
• Clarified meaning of totalSfntSize.
• Defined what is meant by a well formed input font.
• Clarified meaning of 'invalid metadata' - must be well-formed, compressed, and conform to the schema.
• Clarified which elements and attributes in the XML are required;for elements, clarified their required parents.
• Clarified that the id attribute is not of type ID in the XML sense
• Added link to a RelaxNG grammar, which tries to express the same constraints as the prose in a machine-readable manner. The prose is normative in case of any difference.
• Added reminder to check for overflow when decompressing.
• Added a Media Type registration template as required byW3C Media Type registration policies.
• Separated normative and informative references.
• Switched to upper-case for RFC-2119 keywords.
• Added id and class attributes to all testable assertions.
• Added some non-normative explanatory notes.
• Minor clarifications to wording throughout.
• Some re-ordering of text to group related assertions or to improve readability; in particular, the best practices were previously an appendix and are now integrated into the main body of the specification.
• Added this Changes appendix.

The following changes were made as a result of Last Call:

• Language attributes now reference BCP47, and usexml:lang.
• Added optionaldiv andspan elements that can be used to provide structure within metadata text.
• Addeddir andclass attributes to metadata elements.
• Removed summary of conformance requirements (duplicated material from the main body of the specification).
• Somewhat rearranged and clarified description of the metadata format.
• Noted that same-origin requirements are at risk, in the expectation that CSS3 Fonts will handle this instead.
• Mention the need to compute the binary search fields when reconstructing an sfnt header.
• Require that metadata be encoded in UTF-8, rather than allowing either UTF-8 or UTF-16.

Acolor-coded diff between the editors draft used to prepare the Last Call Working Draft, and the editors draft used to prepare the Candidate Recommendation, is available.

The following changes were made after publication of the Candidate Recommendation:

• Removed (previously at-risk) text specifying same-origin requirementsfor loading WOFF fonts, and CORS mechanism to relax the restriction,as the CSS WG agreed to include this in CSS3 Fontsas part of the specification of the @font-face rule.
• Moved CSS3-Fonts from normative to informative section, due to removal of at-risk items.
• Corrected erroneous use of MUST in a general introductory statement

Acolor-coded diff between the editors draft used to prepare the Candidate Recommendation, and the editors draft used to prepare the Proposed Recommendation, is available.

The following changes were made after publication of the Proposed Recommendation:

• The security considerations section of the Media Type Registration appendix was updated to point into the body of the specification,alerting the reader to the private data block and indicating that WOFF does not provide a mechanism to execute any binary code that might becontained therein. This change was made at the request of the IANA Expert Reviewer.

References

Normative References

[BCP47]

BCP 47 Tags for Identifying Languages and Matching of Language Tags

[OFF]

Open Font Format specification (ISO/IEC14496-22:2009).

[RFC-2119]

RFC 2119: Key words foruse in RFCs to Indicate Requirement Levels. S. Bradner, Editor. Internet Engineering Task Force, March 1997.

[ZLIB]

RFC 1950 ZLIBCompressed Data Format Specification. P. Deutsch, J-L. Gailly, Editors. Internet Engineeering Task Force, May 1996.

Informative References

[Compress2]

zlib compress2() function

[CSS3-Fonts]

CSS Fonts Module Level 3. J. Daggett, Editor. World Wide Web Consortium, 4 October 2011. Thelatest version of CSS3 Fonts is available at http://www.w3.org/TR/css3-fonts/. (Work in Progress).

[OpenType]

Microsoft OpenTypespecification, version 1.6. Microsoft, 2009. OpenType is a registered trademark of MicrosoftCorporation.

[TrueType]

AppleTrueType Reference manual. Apple, 2002. TrueType is a registered trademark of AppleComputer, Inc.

[Uncompress]

zlib uncompress() function

[XML]

Extensible Markup Language