Os/2 fsType embedding bits and web fonts

[Also sent to OpenType developer list. Previously circulated among a 
number of font developers for comment and feedback; they have been 
encouraged to follow-up on this list.]


The OpenType font format includes bit settings in the OS/2 table fsType 
bit range that 'indicate font embedding licensing rights for the 
font'[1]. The relevance of these embedding bits to font linking in web 
documents is not clear either from the OT specification or from usage, 
and should be clarified. The OT spec reads

	Embeddable fonts may be stored in a document.
	When a document with embedded fonts is opened
	on a system that does not have the font installed
	(the remote system), the embedded font may be
	loaded for temporary (and in some cases, permanent)
	use on that system by an embedding-aware application.
	Embedding licensing rights are granted by the vendor
	of the font.

	The OpenType Font Embedding DLL Specification and DLL
	release notes describe the APIs used to implement
	support for OpenType font embedding and loading.
	Applications that implement support for font embedding,
	either through use of the Font Embedding DLL or through
	other means, must not embed fonts which are not licensed
	to permit embedding. Further, applications loading
	embedded fonts for temporary use (see Preview & Print
	and Editable embedding below) must delete the fonts when
	the document containing the embedded font is closed.

In this context, 'embedding' may be reasonably interpreted to mean 
stored in a document, but not stored elsewhere and linked to from a 
document.

However, the fsType bits are duplicated in the headers of Microsoft's 
EOT web font format, and are referenced in the EOT specification as 
submitted by Microsoft to the W3C in March 2008[2]. This strongly 
suggests an implicit interpretation of 'embedding' as including web font 
linking, even though the text of the EOT spec merely reiterates what is 
stated in the OT spec:

	The "fsType" entry of the EMBEDDEDFONT structure
	provides an easily accessible copy of the font
	embedding licensing rights for the font in the
	.EOT file. This allows User Agents the ability
	to verify licensing privileges for using the
	embedded font before unpacking and installing the
	font.

	Applications that implement support for font
	embedding must not embed fonts which are not
	licensed to permit embedding. Further, applications
	loading embedded fonts for temporary use (see
	Preview & Print and Editable embedding below) must
	delete the fonts from the device when the document
	containing the embedded font is closed.

Now, this interpretation of embedding and, hence, of the fsType 
embedding bits is problematic, because very many fonts that are licensed 
for embedding in certain kinds of documents, e.g. PDFs, and for certain 
kinds of purposes, e.g. delivery to a service bureau, are not licensed 
for web font linking or, indeed, for all kinds of document embedding. 
The embedding bits are not sufficient to capture all the subtleties of 
licensing rights, so font developers habitually set the embedding bits 
to enable the actual uses to which a font may legitimately be used, 
while making clear elsewhere, in the license agreement, the limitations 
to embedding rights. It follows that the EOT spec is erroneous in 
claiming that the fsType entry 'provides an easily accessible copy of 
the font embedding licensing rights for the font'; rather, the fsType 
entry indicates that *some* embedding rights may be granted by the 
license agreement. It further follows that fonts that have embedding 
bits set to permit some forms of document embedding should *not* be 
presumed to be licensed for web font linking.

I think it is reasonable to say that, over the past decade, PDF has been 
the single most common document format in which fonts are embedded, and 
the majority of font developers have set embedding bits specifically 
with PDF in mind. The fact that most common PDF creation software 
honours the embedding bits, has encouraged font developers to set these 
bits in order to enable the level of embedding in PDF permitted by their 
license agreements. Although the embedding bits are also relevant to 
other document types, e.g. MS Word .doc files, it is primarily in terms 
of PDF that font developers have interpreted 'embedding' and set these 
bits. Font developers have not, in any significant numbers, interpreted 
embedding in terms of web font linking.


With this in mind, and to encourage clarity and avoid misinterpretation, 
by both font developers and software makers, I would like to propose a 
revision to the OpenType specification and inclusion in the 
specifications of web font formats such as WOFF and CWT (formerly EOTL).

1. The OpenType OS/2 fsType specification should clarify the meaning of 
'embedding', and limit this meaning to 'stored in a document', 
explicitly *not* linking to a font stored outside the document. The 
fsType embedding bits should be identified as not relevant to web font 
linking.

2. Web font format specification should explicitly indicate that the 
OS/2 embedding bits are not relevant to web font linking, and should be 
ignored by browsers. This is most important for CWT, since it inherits 
inclusion of the fsType entry in its headers from the EOT format.


As I understand it, browsers implementing naked TTF/OTF font linking are 
already ignoring the fsType embedding bits. This change to the OT spec 
would clarify that they are right to do so. By the same token, it means 
that neither users nor browsers can claim or assume that bit settings 
that permit embedding also permit web font linking.


John Hudson


[1] http://www.microsoft.com/typography/otspec/os2.htm#fst
[2] http://www.w3.org/Submission/2008/SUBM-EOT-20080305/

Received on Tuesday, 20 October 2009 19:53:57 UTC