WOFF File Format 1.0

1. Introduction

This document specifies a simple compressed file format for fonts, designed primarily for use on the web. The WOFF format is a container for the table-based sfnt structure used in TrueType[1], OpenType[2] and Open Font Format[3] fonts, which are collectively referred to as sfnt-based fonts. A WOFF file is simply a repackaged version of a sfnt-based font with optional compression of the font data tables. The WOFF file format also allows font metadata and private-use data to be included separately from the font data. WOFF encoding tools convert an existing sfnt-based font into a WOFF formatted file, and user agents restore the original sfnt-based font data for use with a web page.

In general, the structure and contents of decoded font data exactly match those of the original font file. Tools producing WOFF files may provide other font editing features such as glyph subsetting, validation or font feature additions but these are considered outside the scope of this format. Independent of these features, both tools and user agents must assure that the validity of the underlying font data is preserved.

The primary purpose of the WOFF format is to package fonts linked to web pages by means of CSS @font-face rules. When using such fonts, user agents MUST implement a 'same-origin restriction' on the downloading of WOFF files using the same-origin matching algorithm described in the HTML5 specification[4]. Note that the origin of the stylesheet containing @font-face declarations is not used when deciding whether a WOFF file is same-origin or not, only the origin of containing document is used. User agents MUST also implement the ability to relax this restriction using Cross-Origin Resource Sharing[5]. Thus, sites can explicitly allow cross-site downloading of WOFF files using the Access-Control-Allow-Origin HTTP header.

User agents supporting the WOFF file format for downloadable fonts MUST respect the requirements of the CSS Fonts specification[6]. In particular, such downloaded 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.

Notational Conventions

The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in RFC 2119[7].

2. Overall File Structure

The structure of WOFF files is similar to the structure of sfnt-based 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 in the TrueType[1], OpenType[2] and Open Font Format[3] specifications.

The main body of the file consists of the same collection of font data tables as the original, uncompressed sfnt-based font, stored in the same order, except that each table MAY be compressed, and the sfnt table directory is replaced by the WOFF table directory.

A complete WOFF file consists of 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 extended metadata, and an optional block of private data. Except for padding with a maximum of three null bytes in places where 4-byte alignment of a table length or data block is specified, there MUST NOT be any extraneous data outside the font tables and data blocks as pointed to by the header and table directory entries.

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

3. WOFF Header

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

The flavor 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.0 as 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 the flavor field contains a different value, indicating a WOFF-packaged version of a different sfnt flavor. (The value 0x74727565 'true' has been used for some TrueType-flavored fonts on Mac OS, for example.) Whether client software will actually support other types of sfnt-based font data is outside the scope of the WOFF specification, which simply describes how the sfnt is repackaged for Web use.

The WOFF majorVersion and minorVersion fields specify the version number for a given WOFF file, which can be based on the version number of the original font but is not required to be. These fields have no effect on font loading or usage behavior in user agents.

The totalSfntSize field is the sum of the uncompressed font table sizes, each padded to a multiple of 4 bytes, plus the size of the sfnt header and table directory. Thus, this is the size of buffer needed to decode the complete WOFF-packaged font (but not metadata, which is not part of the original sfnt file) into a standard sfnt structure. Note that this value MUST be a multiple of 4, because all font tables including the last are to be padded to a 4-byte boundary. If this value is incorrect, a conforming WOFF processor MUST reject the file as invalid.

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 offset and length fields pointing to the metadata or private data block are out of range, indicating a byte range beyond the physical size of the file, a conforming WOFF processor MUST reject the file as invalid.

The header includes a reserved field; this MUST be set to zero. If this field is non-zero, a conforming WOFF processor MUST reject the file as invalid.

4. Table Directory

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

The format of tag values are defined by the specifications for sfnt-based fonts. The offset and compLength fields identify the location of the compressed font table. The origLength and origCheckSum fields are the length and checksum of the original, uncompressed font table from the table directory of the original font.

The sfnt-based format specifications require that font tables be aligned on 4-byte boundaries. Font tables whose length is not a multiple of 4 are padded with null bytes up to the next 4-byte boundary. Font data tables in the WOFF file have the same requirement: they MUST begin on 4-byte boundaries and be padded with nulls to the next 4-byte boundary. The compLength and origLength fields in the header store the exact, unpadded length.

If the length of a compressed font table would be the same as or greater than the length of the original font table, the font table MUST be stored uncompressed in the WOFF file and the compLength set equal to the origLength. Tools MAY also opt to leave other tables uncompressed (e.g. all tables less than a certain size), in which case compLength will be equal to origLength for these tables as well. WOFF files containing table directory entries for which compLength is greater than origLength are considered invalid and MUST NOT be loaded by user agents. Files containing compressed font tables that decompress to a size larger than origLength are also considered invalid and MUST NOT be loaded.

The sfnt-based font specifications require that the table directory entries are sorted in ascending order of tag value. To simplify processing, WOFF-producing tools MUST produce a table directory with entries in ascending tag value order. User agents MUST likewise assure that the sfnt table directory is recreated in ascending tag order when restoring the font data to its uncompressed state. The ordering of the font tables themselves is independent of the order of directory entries, as described below.

sfnt-based fonts store a checksum for each table in the table directory, and an overall checksum for the entire font in the head table (see the TrueType, OpenType or Open Font Format specifications for the definition of each calculation). Tools producing WOFF files MUST validate these checksums, and correct the values and/or issue an error message if a discrepancy is found.

A WOFF file contains the same set of font tables as the original font from which it was created. This means that the overall font checksum of a font decompressed from a conformant WOFF file should always match the checksum in the original, valid sfnt-based font file, except in the case where the original file included unreferenced data between or after the actual tables; this would affect the overall checksum of the original font, but would be dropped during creation of the WOFF file.

In cases where checksum recalculation is necessary or changes to the original font data are made, e.g., to subset the glyphs in the font or add special tables, conformant tools MUST either remove any digital signature (i.e., a DSIG table) or regenerate the signature (if the necessary credentials are available), and MUST correct all affected checksum values and table offsets, both for individual tables and the overall font data checksum contained in the head table.

Unless the original font has incorrect checksums that are corrected by the WOFF file generator, or extraneous data between tables (discarded by the WOFF generator), the result of creating a WOFF file and then decoding this to regenerate an sfnt font MUST result in a final font that is bitwise-identical to the original.

5. Font Data Tables

The font data tables in the WOFF file are exactly the same as the tables in the original sfnt-based font file, except that each table MAY have been compressed by the compress2() function of zlib[8] (or an equivalent, compatible algorithm). User agents use a function equivalent to the uncompress function of zlib[9] to decompress each table. The underlying format these functions use is described in the ZLIB specification[10].

User agents or other programs that decode WOFF files MUST be able to handle tables that have been compressed. However, the use of compression for font data tables is OPTIONAL for tools generating WOFF files; storing the tables in uncompressed form is permissible.

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

Font tables in WOFF files SHOULD be stored in the same order as the original sfnt-based font and user agents SHOULD restore the original uncompressed font table in identical order if reconstituting the complete font into an sfnt structure. The table order is implied by offset values in the table directory; sorting table directory entries into ascending offset value order produces a list of entries in an order equivalent to that of the font tables.

If either a WOFF-creation tool or a WOFF-consuming user agent reorders or otherwise modifies the collection of font tables, it MUST recalculate the font checksum in the head table, which will be affected by the changed offsets in the sfnt table directory, and remove any DSIG table that is invalidated by the changes. A new signature MAY be added to the modified font, as described by the OpenType and Open Font Format specifications (if appropriate signing credentials are available to the tool involved).

6. Extended Metadata Block

The WOFF file MAY include a block of extended metadata, allowing the inclusion of more extensive metadata than is present directly in the original sfnt-based font file. The metadata block consists of XML data compressed by zlib; the file header specifies both the size of the actual compressed and the original uncompressed size in order to facilitate memory allocation.

If present, the metadata MUST be compressed; it is never stored in uncompressed form. If no extended metadata is present, the metaOffset, metaLength and metaOrigLength fields in the WOFF header MUST be set to zero.

The metadata block MUST follow immediately after the last font table. As font tables MUST be padded with null bytes to a 4-byte boundary, the beginning of the metadata block will always be 4-byte aligned. The end of the metadata block is not padded to a 4-byte boundary unless it is followed by a private data block (below).

If the extended metadata is invalid (for example, the data cannot be decompressed, or it is not well-formed XML), the WOFF processor MUST proceed as if the metadata block is absent; the font itself remains valid and can still be used (provided its main content of font data tables is valid).

The presence (or absence) and content of the metadata block MUST 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's name table entries when relevant extended metadata elements are not present.

The extended metadata MUST be well-formed XML. The use of UTF-8 encoding is recommended.

Several elements store their data in text subelements; this is to support localization. The text elements MAY be given a lang attribute. The possible values for the lang attribute can be found in the IANA Subtag Registry[11]. A user agent displaying metadata is expected to choose a preferred language/locale to display from among those available, following RFC 4647[12]. The user agent SHOULD choose which of the available text elements to display as follows:

1. If a text element is available in the user's preferred language, as determined via an 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 or defaults, try each of these in turn and use the first one found.
3. If there is a text element with no lang attribute, use this; in the event that more than one exists, use the first of them.
4. If no match is found yet, use the first text element. (Thus, the metadata creator can determine the "localization of last resort" simply by choosing which language to put first in each group of text elements.)

Such localizable elements are indicated by the statement "This element may be localized" in the description below; the internal structure of text elements with lang attributes is not repeated for each element type.

metadata element

The main element. This element is required.

attributes
version	A version number indicating the format version of the metadata element. This is currently 1.0. This attribute is required.

All first-level subelements of the metadata are optional, and may occur in any order as children of the top-level metadata element.

The extension element is intended to allow vendors to include metadata that is not covered by the specific elements defined here, while following a standard model. User agents that provide a means for the user to view WOFF file metadata SHOULD include such extension elements in the metadata presented to the user.

In addition, vendors MAY include additional types of metadata as new elements within the metadata element, or as additional attributes of the elements specified here. Such additional elements or attributes MAY be ignored by conforming user agents, or MAY be used (e.g., displayed to the user on request).

uniqueid element

A unique identifier string for the font. This element is recommended, but not required for the metadata to be valid. This element must be a child of the metadata element. This is an empty element.

attributes
id	The identification string.

The string defined in the uniqueid element is not guaranteed to be truly unique, as there is no central registry or authority to ensure this, but it is intended to allow vendors to reliably identify the exact version of a particular font. The use of "reverse-DNS" prefixes to provide a "namespace" is recommended; this can be augmented by additional identification data of the vendor's own design.

vendor element

Information about the font vendor. This element is recommended, but not required for the metadata to be valid. This element must be a child of the metadata 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 is optional.

credits element

Credit information for the font. This can include any type of credit the vendor desires: designer, hinter, and so on. This element is optional. If present, it must be a child of the metadata element and it must contain at least one credit element. This element has no attributes.

Subelements:

credit element

A single credit record. If present, it must be a child of the credits 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 is optional.
role	The role of the entity being credited. This attribute is optional.

description element

An arbitrary text description of the font's design, its history, etc. This element is optional. If present, it must be a child of the metadata element. This element may be localized.

license element

The license for the font. This element is optional. If present, it must be a child of the metadata element. This element may be localized.

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 is optional.

copyright element

The copyright for the font. This element is optional. If present, it must be a child of the metadata element. This element may be localized. This element has no attributes.

trademark element

The trademark for the font. This element is optional. If present, it must be a child of the metadata element. This element may be localized. This element has no attributes.

licensee element

The licensee of the font. This element is optional. If present, it must be a child of the metadata element. This is an empty element.

attributes
name	The name of the licensee. This attribute is required.

extension element

A container element for extended metadata provided by the vendor. Zero or more extension elements may be present as children of the top-level metadata element. Each such metadata extension has an optional name, which may be provided in multiple languages, and one or more item elements.

attributes
id	An arbitrary identifier defined by the vendor. This attribute is optional.

Subelements:

name element

Zero or more name elements may be used to provide a human-friendly name for the collection of extended metadata items. A user agent that displays metadata SHOULD choose the name with most the appropriate language from among those available for each named extension element. This subelement is OPTIONAL; anonymous extension elements are also permissible.

attributes
lang	A language tag as defined in the IANA Subtag Registry. This attribute is optional.

item element

At least one item element SHOULD be present in each extension container.

attributes
id	An arbitrary identifier defined by the vendor. This attribute is optional.

Subelements:

name element

One or more name elements are used to provide a human-friendly name for a specific extended metadata item. A user agent that displays metadata SHOULD choose the name with the most appropriate language from among those available for each item element. This subelement is REQUIRED; an item element with no name is invalid and SHOULD be ignored.

attributes
lang	A language tag as defined in the IANA Subtag Registry. This attribute is optional.

value element

One or more value elements are used to provide the value of a specific extended metadata item. A user agent that displays metadata SHOULD choose the value with the most appropriate language from among those available for each item element. This subelement is REQUIRED; an item element with no value is invalid and SHOULD be ignored.

attributes
lang	A language tag as defined in the IANA Subtag Registry. This attribute is optional.

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

7. Private Data Block

The WOFF file MAY include a block of arbitrary data, allowing font creators to include whatever information they wish. The content of this data MUST NOT affect font usage or load behavior. WOFF processors should make no assumptions about the content of a private block; it may (for example) contain ASCII or Unicode text, or some vendor-defined binary data, and it may be compressed or encrypted, but it has no publicly defined format. Conformant user agents will not assume anything about the structure of this data. Only the font developer or vendor responsible for the private block is expected to understand its contents.

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 data block MUST begin on a 4-byte boundary in the WOFF file, with up to three null bytes inserted as padding if needed to ensure this. No padding is required at the end of the private data block; any following data does not form part of the WOFF file structure, and MUST be ignored.

If no private data is present, the privOffset and privLength fields in the WOFF header MUST be set to zero. However, as a conforming WOFF processor does not interpret or even need to access the private data in any way, it will simply ignore these fields. Only a private vendor-specific tool would use them.

8. Summary of Conformance Requirements

This section summarizes key conformance requirements for WOFF files, derived from the more detailed specifications above. Tools creating WOFF files MUST ensure that the results conform to these requirements, and unless otherwise specified here, user agents processing or using WOFF files MUST reject any non-conforming input files.

WOFF header

signature

MUST be the value 0x774F4646

length

MUST match the total length of the WOFF file

reserved

MUST be zero

offset and length of metadata and private blocks

MUST be zero, or point to valid ranges of the WOFF file

totalSfntLength

MUST match the total size required for the decoded sfnt data, including header, table directory, decompressed tables, and padding of all table lengths to 4-byte boundaries

WOFF directory

The table directory entries MUST be in ascending order according to table tag. Within each entry:

compLength

MUST be less than or equal to origLength

origChecksum

MUST be correct for the original table data, in accordance with the OpenType specification

offset

MUST be a multiple of 4

Font tables

For each table where (in the WOFF table directory) compLength < origLength, processing the data with zlib's uncompress() function MUST result in exactly origLength bytes of decompressed data.

For each table where compLength is not a multiple of 4, the WOFF file MUST be padded with up to 3 zero bytes so as to reach a 4-byte boundary.

Metadata

Processing the metadata with zlib's uncompress() function MUST result in metaOrigLength bytes of decompressed data.

The decompressed data MUST be well-formed XML; however, if the metadata block is not well-formed, user agents MUST NOT reject the entire WOFF file. They MAY provide some form of warning or error indication to the user, but MUST proceed to render the contained font as if the metadata block were absent. This requirement is designed to maximize interoperability between clients that interpret the metadata block and those that do not support it at all.

Appendix A: Extended Metadata Examples

This "dummy" metadata block illustrates the use of the metadata elements described in section 6, including the use of multiple text elements to provide localized versions of certain elements.

<?xml version="1.0" encoding="UTF-8"?>
<metadata version="1.0">
    <uniqueid id="com.example.fontvendor.demofont.rev12345" />
    <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 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"
             id="fontvendor-web-corporate-v2">
        <text lang="en">A license goes here.</text>
        <text lang="fr">Un permis va ici.</text>
    </license>
    <copyright>
        <text lang="en">Copyright ©2009 Font Vendor"</text>
        <text lang="ko">저작권 ©2009 Font Vendor"</text>
    </copyright>
    <trademark>
        <text lang="en">Demo Font is a trademark of Font Vendor</text>
        <text lang="fr">Demo Font est une marque déposée de Font Vendor</text>
        <text lang="de">Demo Font ist ein eingetragenes Warenzeichen der Font Vendor</text>
        <text lang="ja">Demo FontはFont Vendorの商標である</text>
    </trademark>
    <licensee name="Wonderful Websites, Inc." />
    <extension id="org.example.fonts.metadata.v1">
        <name lang="en">Additional font information</name>
        <name lang="fr">L'information supplémentaire de fonte</name>
        <item id="org.example.fonts.metadata.v1.why">
            <name lang="en">Purpose</name>
            <name lang="fr">But</name>
            <value lang="en">This font exists merely as an example of WOFF packaging.</value>
            <value 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 id="com.fontfont.PraterScriptWeb.7.504.1002"/>
   <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/eula/license_webfonts_v_1_0.html" id="fontfont-web-v1">
       <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 the uniqueid and licensee elements modified to be unique for each customer.

<?xml version="1.0" encoding="UTF-8"?>
<metadata version="1.0">
<uniqueid id="037d0f6b-b5e3-b841-05afa509061b" />
<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 Ascender
Corporation and/or its suppliers and its use by you is covered under the
terms of the Web Font license agreement between you and Ascender
Corporation. You may ONLY use this font software with the licensed web site.
Except as specifically permitted by the license, you may not copy this font
software. If you have any questions, please contact Ascender Corp.</text>
</license>
<licensee name="FontsLive.com" />
</metadata>

Appendix B: Best Practices for WOFF File Creators

This appendix highlights aspects of the WOFF specification that are particularly relevant to those creating or packaging fonts in WOFF format, and provides recommended Best Practices for tools or workflows involved in WOFF file creation.

Ensure round-trip fidelity

Any valid WOFF file can be converted back to sfnt format, by decompressing the individual font tables and reconstructing the sfnt header and table directory. The resulting font should always be structurally valid and functionally equivalent to the original font prior to packaging in WOFF format.

However, it is recommended that the result of such a round-trip conversion to WOFF format and back to sfnt should be not only functionally equivalent to the original, but actually bitwise identical. For this to hold true, the original sfnt file should conform to certain norms that are not strictly required by the OpenType/OFF specification, although they are common practice:

Font table padding

The OpenType/OFF specification is not entirely clear about whether all tables in an sfnt font must be padded with 0-3 zero bytes to a multiple of 4 bytes in length, or whether this applies only between 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-byte boundary, including the last. The WOFF specification assumes this behavior, and specifies that the totalSfntLength field in the WOFF header provides for such padding. To ensure that a given font can be packaged as a WOFF file and then decoded to 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 the presence 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 no provision to preserve such non-font-table data when packaging a font, and therefore it would not survive a round-trip format conversion.

Ensure checksums are correct

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

In addition, WOFF creation tools should preserve the order of the font tables. While this is not required for validity or for correct functioning of the font, it is necessary to allow binary round-trip fidelity; and if this is not ensured, then the sfnt checksum and digital signature (if any) can no longer be validated, as these are affected by table ordering.

Distinguish WOFF packaging from other preprocessing and optimization

The WOFF format provides a standard way to package the collection of tables that make up a font, together with added metadata, for delivery to a web browser or other client. It is not concerned with the actual content of the font tables, or how they are used once decoded by the user agent.

In some cases, sites deploying WOFF files as web fonts may wish to subset the character repertoire, optimize table ordering for efficient text layout or rasterization, or remove (or add) optional font tables depending on the particular features needed for a site. These or similar operations are considered modifications to the original font, yielding a new "original" font that becomes the source for WOFF packaging; such modifications are outside the scope of the WOFF specification itself.

Appendix C: Best Practices for WOFF File Consumers

This appendix highlights aspects of the WOFF specification that are particularly relevant to those using fonts in WOFF format (typically user agents such as web browsers), and provides recommended Best Practices for WOFF file use.

Reject files that violate basic conformance requirements

Any file that claims to be a WOFF file but fails to satisfy the conformance requirements summarized in section 8 is not a valid WOFF file, and user agents must not attempt to decode and use font data from such a file.

Note that the WOFF specification does not guarantee that the actual font data packaged in a valid WOFF container is in fact correct and usable. It requires only that the WOFF packaging structure—header, table directory, and compressed tables—conforms to this specification. The contained data must be used with just as much caution as font data delivered in "raw" form or via any other packaging method.

Check all uncompress operations for overflow

For each compressed data block, the WOFF format specifies the uncompressed size. This allows the client to allocate appropriate amounts of space for decompression. Clients must check that the uncompress() operation yields exactly the specified amount of data, and does not return an error. Any error in decompression or discrepancy in table size means the WOFF file is invalid and must not be used.

Ensure reconstructed sfnt resources are valid

Many clients may choose to "decode" the WOFF-packaged data and construct an sfnt font resource in memory, for use with existing font APIs. This can be done either completely, reconstructing the exact same sfnt data as was originally packaged in the WOFF file, or partially by including or excluding specific font tables according to the client's requirements. For example, a client that does not support a particular text layout technology (such as OpenType layout, AAT, or Graphite) might choose to omit tables that are not relevant to its text-rendering system. In this case, the client should ensure that font-wide fields such as the head table checksum or any digital signature table are updated appropriately so that the resulting sfnt resource is valid according to the OpenType specification.

In practice, this means that if a client does "partial" reconstruction of a digitally signed font, it should remove the DSIG table as it will not be a valid signature for the modified font resource.

Provide means for the user to view WOFF metadata

Clients such as web browsers are encouraged to provide a means (such as a Page Information dialog) for users to view the metadata included in WOFF files. Not every client will necessarily have an appropriate context for this, but any client that enables the user to find out about the resources used by a web page should consider exposing information about the fonts used, and in the case of WOFF-packaged fonts, the metadata block is the primary source of this information.

WOFF files are not installable fonts

The WOFF format is intended for use with @font-face to provide downloadable fonts linked to specific web pages, and (in accordance with the CSS Fonts specification[6]) fonts used in this manner must not be made available to other documents or applications. It is therefore recommended that WOFF files should not be treated as an installable font format in desktop operating systems or similar environments. The WOFF-packaged data will typically be decoded to its original sfnt format for use by existing font-rendering APIs that expect OpenType font data, but such a decoded font should not be exposed as a file on disk, and must not be installed "globally" for use by other processes or documents on the system.

Footnotes

[1]

Apple TrueType specification. TrueType is a registered trademark of Apple Inc.

[2]

Microsoft OpenType specification. OpenType is a registered trademark of Microsoft Corporation.

[3]

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

[4]

HTML5. See Section 5.3: Origin.

[5]

Cross-Origin Resource Sharing

[6]

CSS Fonts Module Level 3. See Section 4.1: The @font-face rule.

[7]

RFC 2119 (Key words for use in RFCs to Indicate Requirement Levels)

[8]

zlib compress2() function

[9]

zlib uncompress() function

[10]

RFC 1950 (ZLIB Compressed Data Format Specification)

[11]

IANA Language Subtag Registry

[12]

RFC 4647 (Matching of Language Tags)