Hi there,
With Nicolas Spalinger's comments about font metadata (13:00 BST today)
fresh in my mind, I want to ask what the open font community thinks
about this proposal. As I understand it, this proposal is intended to
*replace* OTF/TTF font linking. Unlike another proposal, it does not
allow any kind of backward compatibility with any version of 'EOT',
Microsoft's system for font linking in Internet Explorer from version 4
upwards.
If you need the 'history' of this proposal and others, it is all on the
w3c's www-font list.
Ben
-------- Original Message --------
Subject: WebOTF Proposal
Resent-Date: Thu, 06 Aug 2009 19:11:33 +0000
Resent-From: www-f...@w3.org
Date: Thu, 6 Aug 2009 15:10:51 -0400
From: Tal Leming <t...@typesupply.com>
To: www-font <www-f...@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.
Tal
--
Ben Weiner | http://readingtype.org.uk/about/contact.html
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:
WebOTFFile:
WebOTFHeader
TableDirectory[]
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.
Header
======
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:
WebOTFHeader:
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.
TableDirEntry:
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
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Much of this was inspired by the Dublin Core Metadata Initiative.
http://dublincore.org
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.
Attributes:
id (REQUIRED)
This is an empty element.
-->
<uniqueid id="uk.co.fontvendor.demofont.rev12345" />
<!--
SHOULD have vendor, source or maintainer info.
Attributes:
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>
elements.
-->
<designcredits>
<!--
There is one <designer> element for each designer or
other contributor to be recorded.
Attributes:
name (REQUIRED)
url (OPTIONAL)
role (OPTIONAL)
This is an empty element.
-->
<designer name="Font Designer"
url="http://fontdesigner.com";
role="Lead" />
<designer name="Another Font Designer"
url="http://anotherfontdesigner.com";
role="Contributor" />
<designer name="Yet Another"
role="Hinting" />
</designcredits>
<!--
MAY have an arbitrary text description of the font's
design, its history, etc.
-->
<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.com.
</text>
</description>
<!--
MAY have license text and/or URL to licensing info.
Attributes:
url (OPTIONAL)
-->
<license url="http://fontvendor.com/license";>
<text lang="en">A license goes here.</text>
<text lang="fr">Un permis va ici.</text>
</license>
<!--
MAY have copyright text.
-->
<copyright>
<text lang="en">Copyright ©2009 Font Vendor"</text>
<text lang="ko">ì ìê¶ Â©2009 Font Vendor"</text>
</copyright>
<!--
MAY have trademark text.
-->
<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>
<!--
MAY have an element specifying the licensee.
Attributes:
name (REQUIRED)
This is an empty element.
-->
<licensee name="Wonderful Websites, Inc." />
</metadata>
