W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

WebOTF Proposal

From: Tal Leming <tal@typesupply.com>
Date: Thu, 6 Aug 2009 15:10:51 -0400
Message-Id: <1ED663A2-EE29-48B7-9607-C617ACACFAC0@typesupply.com>
To: www-font <www-font@w3.org>
We, (Jonathan Kew, Erik van Blokland and myself) have combined our ZOT  
and .webfont proposals into a new WebOTF proposal. The full  
specification is attached.

In short:
- The ZOT compression scheme is retained.
- The XML data from the .webfont proposal, in a reduced and refactored  
form, is stored within the WebOTF file.

We are still endorsing the same-origin restrictions and CORS concepts  
that have been discussed. We are still hopeful that browsers will find  
ways to display the meta data stored in the font.

We'd love to know what you think.


Enhanced OpenType for web use: the WebOTF format
August 6, 2009

Jonathan Kew, Mozilla Corp.
Tal Leming, Type Supply
Erik van Blokland, LettError

This is a proposal for a simple compressed format for fonts, designed primarily for use on the web. A feature of this format is that clients can decompress individual tables as needed, and thus can access specific parts of the font data without the need to decompress the entire font. In resource-constrained environments such as mobile devices, this allows the user agent to examine, for example, the OS/2 and cmap tables quite cheaply; or a client that knows it is doing horizontal layout could skip decompressing a vertical metrics table.

It would even be possible for the UA to use byte-range requests to avoid even downloading the entire compressed file, by first downloading the header, to determine the number of tables, and then the table directory. At this point, the UA can issue a request to get the compressed version of any individual font table, and thus it can minimize the RAM footprint of pages that may link to numerous fonts, at the cost of doing more separate network requests.

This format does not provide for individual decompression of single glyphs; it is expected that sites using linked fonts for CJK languages, or using large-character-inventory fonts like Arial Unicode, Code2000, Lucida Grande, etc. (subject to proper licensing), will subset the fonts appropriately before applying WebOTF compression/packaging.

The extension ".webotf" is suggested for files using this format.

Overall file structure

All values in the WebOTF file are stored in big-endian format, like TrueType and OpenType.

The WebOTF file consists of a 44-byte header, followed by a variable-size table directory, a number of OpenType fonts tables, an optional block of extended metadata, and an optional block of private data:

  OpenType Tables[]
  Extended Metadata
  Private Data

The main body of the file consists of the same collection of tables as the original uncompressed OpenType font, with one exception; each table is separately compressed (see below), and the OpenType table directory is replaced by the WebOTF table directory.

The exception mentioned above is that any DSIG table, if present, is removed from the font. This is because the process of compression and subsequent decompression will invalidate the signature, as the reconstituted font will (normally) not be binary-identical to the original. If digital signature support is required, it would be possible to specify a new signature table for the compressed font, along the same lines as DSIG in OpenType; existing tools could easily be extended to support this, as the two formats are so similar in overall structure.


The header includes an identifying signature and indicates the kind of OpenType data included in the file; it also has a font version number, offsets to additional data chunks, and the number of entries in the following table directory:


  UInt32    signature      0x774F5446 ('wOTF')
  UInt32    flavor         The "sfnt version" of the original file
                           (i.e., 0x00010000 or 'OTTO')
  UInt16    majorVersion   Version of the WebOTF font
  UInt16    minorVersion
  UInt32    length         Total size of the WebOTF file
  UInt32    metaOffset     Offset to metadata block, from beginning of WebOTF
  UInt32    metaLength     Length of compressed metadata block
  UInt32    metaOrigLength Uncompressed size of metadata block
  UInt32    privOffset     Offset to private data block
  UInt32    privLength     Length of private data block
  UInt32    numTables      Number of entries in directory of OpenType tables
  UInt32    totalSize      Total size of the uncompressed OpenType tables

Table directory

The table directory follows immediately after the file header.

Each entry in the table directory is 20 bytes. The entries must be sorted in ascending order by tag, to permit binary search.


  UInt32    tag           4-byte table identifier (see OT spec)
  UInt32    offset        Offset to the data, from beginning of WebOTF file
  UInt32    compLength    Length of the compressed data (see note below)
  UInt32    origLength    Length of the uncompressed table (from OT table dir)
  UInt32    origChecksum  Checksum of the uncompressed table (see OT spec)

NOTE: It is possible that some tables, particularly small ones, may not be worth compressing. It is permissible to store the original table, uncompressed, in the WebOTF file. This is indicated by compLength >= origLength in the table directory. Therefore, a tool creating WebOTF fonts MUST check that the compressed data for each table is smaller than the original uncompressed data. If this is not the case, it MUST store the table in uncompressed form. (NB: it is possible for compLength to be larger than origLength in this case, because the uncompressed table may have up to 3 bytes of padding at the end which are not included in the origLength count.)

OpenType Tables

The OpenType tables in the WebOTF file are exactly the same as the tables in the original OpenType file, except that each table may have been compressed by the compress2() function of zlib. Tables may be stored in any order. There is no requirement for any specific alignment of tables or padding between tables, except that when a table is stored uncompressed (see above), it MUST begin on a 4-byte boundary and be padded with zeros if necessary so that its length is a multiple of 4. The "compLength" field in the table directory will record the complete (padded) length of the table data, and may therefore be up to 3 bytes larger than the "origLength".

Metadata Block

The WebOTF font file may optionally include a block of extended metadata, allowing the inclusion of more extensive metadata than is present directly in the OpenType font. 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. The metadata (if present) is always compressed, never stored in uncompressed form.

If no extended metadata is present, the offset and lengths in the WebOTF header should be set to zero.

If the extended metadata is invalid (for example, the offset/length indicate a range outside of the actual WebOTF file, or the data cannot be decompressed, or it is not well-formed XML), the WebOTF processor should proceed as if the metadata block is absent; the font itself can still be used (provided its OpenType data is valid).

WebOTF processors are not required to interpret the extended metadata, which has no influence on the usability of the embedded OpenType font data. However, if they provide a means for users to view information about fonts (such as a "Font Information" panel) then they are encouraged to treat the metadata block as the primary source, falling back on the font's 'name' table entries when extended metadata elements are not present.

The specific format of the XML metadata is still to be determined, in consultation with interested parties. An outline of a possible format is included in Appendix A below.

Private Data Block

The WebOTF font file may optionally include a block of arbitrary data, allowing font creators to include whatever information they wish. WebOTF processors should make no assumptions about the content of any private block; it may (for example) contain ASCII or Unicode text, or some vendor-defined binary data, and it may be compressed and/or encrypted, but as far as WebOTF is concerned it is simply an array of bytes. Only the font developer or vendor responsible for the private block is expected to understand its contents.

If no private data is present, the offset and length in the WebOTF header should be set to zero. However, as a conforming WebOTF 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.

APPENDIX A: Draft of Extended Metadata

<?xml version="1.0" encoding="UTF-8"?>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    "OPTIONAL" in this document are to be interpreted as described in
    RFC 2119.

    Much of this was inspired by the Dublin Core Metadata Initiative.

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

    Vendors MAY include additional types of metadata in new elements
    within the <metadata>; such elements MAY be ignored by conforming
    user agents, or MAY be used (e.g., displayed to the user on request).

    Several elements store their data in <text> subelements; this
    is to support localization. The <text> elements may be given
    a lang attribute; a user agent displaying metadata is expected
    to choose a preferred language from among those available, falling
    back to a default (typically English) or to an unmarked <text>
    element if no better match is found.

<metadata version="1.0">
        MAY have a "unique" identifier. This 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 an identifier such
        as a repository revision number or changeset ID.

            id (REQUIRED)
        This is an empty element.
    <uniqueid id="uk.co.fontvendor.demofont.rev12345" />

        SHOULD have vendor, source or maintainer info.

            name (REQUIRED)
            url (OPTIONAL)
        This is an empty element.
    <vendor name="Font Vendor"
            url="http://fontvendor.com" />

        MAY have design credits.

        The <designcredits> element contains one or more <designer>
            There is one <designer> element for each designer or
            other contributor to be recorded.

                name (REQUIRED)
                url (OPTIONAL)
                role (OPTIONAL)
            This is an empty element.
        <designer name="Font Designer"
                  role="Lead" />
        <designer name="Another Font Designer"
                  role="Contributor" />
        <designer name="Yet Another"
                  role="Hinting" />

        MAY have an arbitrary text description of the font's
        design, its history, etc.
        <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.com.

        MAY have license text and/or URL to licensing info.

            url (OPTIONAL)
    <license url="http://fontvendor.com/license">
        <text lang="en">A license goes here.</text>
        <text lang="fr">Un permis va ici.</text>

        MAY have copyright text.
        <text lang="en">Copyright ©2009 Font Vendor"</text>
        <text lang="ko">저작권 ©2009 Font Vendor"</text>

        MAY have trademark text.
        <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>

        MAY have an element specifying the licensee.

            name (REQUIRED)
        This is an empty element.
    <licensee name="Wonderful Websites, Inc." />


Received on Thursday, 6 August 2009 19:11:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:33 UTC