August 7, 1996
Adobe Systems, Inc. Randy Polen, polen@mv.us.adobe.com
Adobe Systems, Inc. Stephen Zilles, szilles@mv.us.adobe.com
Bitstream Inc. Brad Chase, brad_chase@bitstream.com
Bitstream Inc. Glen Rippel, glen_rippel@bitstream.com
Hewlett Packard Co. Robert Stevahn, rstevahn@boi.hp.com
Microsoft Corporation David M. Meltzer, davidm@microsoft.com
This document discusses solutions for using fonts, referred to as WebFonts, in documents on the World Wide Web. Font declaration, server fonts, matching, and synthesis are addressed, as well as proposals for a new MIME type and a CSS font definition class for defining fonts and their properties. To allow for future font technologies a generalized tag mechanism is used. For backward compatibility, it is assumed if a browser can not interpret the font definitions, then it will gracefully default to a specific font (most often a version of Times).
This document focuses on the syntax and capabilities of WebFont definitions. It is supported by two other W3C drafts, Fonts for the Web: Rationale and How to reference fonts from HTML. Readers should refer to these documents for additional information on the goals and operation of WebFonts.
To expedite work on this draft it is important to identify issues that are have not be worked into the draft but are being addressed. During the month of July we will be addressing the following issues and welcome input.
Style sheets can be associated with (or embedded within) several or specific HTML documents. This provides a mechanism for defining fonts for site-wide use; for defining different subsets of the same font; for overriding site-wide font definitions with page-specific font definitions; or for writing font definitions within an HTML document. Specific interactions between associated style sheets may be controlled by the user or the browser, and are beyond the scope of this document.
When considering font mark-up for style sheets it must be remebered that one style sheet may apply to multiple documents. This is of greatest concern in the area of character set-subsetting. Font names that indicate specific sub-sets and references to specific sub-setted server font resources are not appropriate in shared style sheets.
The ability to attach style sheets has come to HTML in the form of CSS1, or "Cascading Style Sheets, level 1" [Ref6]. CSS1 specifies style sheet syntax while "HTML3 and Style Sheets" [Ref13] specifies ways of incorporating that syntax into HTML using the LINK element for external style sheets and the STYLE element and STYLE property for internal (to the same HTML document) style information.
Within a style sheet the declaration "@fontdef <font name>" is used to define a WebFont. The font name parameter defines the name of the font, and is used to select the font defintion using the font-face or font-family style properties. The font name is case insensitive.
The properties shown below are defined for use within a WebFont declaration. In general, each of these parameters is optional (Not that the src and type parameters should be used together). Authors may specify the relative level of font fidelity required in their document by choosing which WebFont mechanisms to employ.
Additionally, the CSS1 font properties (font-size, font-size-index, font-family, font-weight, font-style, and line-height) may be used to describe the font as an aid in finding fonts for child elements, or a fall-back mechanism when the font definition cannot be successfully resolved in any other may (e.g. a bad URL).
Examples:
The following example shows a fontdef that defines a specific font face. The fontdef also references a panose font description (see Font Descriptions for Synthesis and Matching) and provides a source URL for retrieving a server font. Font-family, font-weight, and font-style properties are provided to describe the font.
<STYLE>
@fontdef Folio Black Oblique {
src: www.fonts.org/sans/folio/black_oblique;
type: font/truetype;
desc: folio-panose;
font-family: Folio, sans-serif;
font-weight: extra-bold;
font-style: oblique;
}
</STYLE>
In this example, the fontdef is used to define a family of fonts. A server font source URL is provided for retreiving the font data. This data file will contain multiple styles and weights of the named font. A font-family property is provided in case the server font cannot be retrieved.
<STYLE>
@fontdef Helvetica {
src: www.fonts.org/sans/Helvetica_family.pfr;
type: font/truedoc;
font-family: Helvetica, sans-serif;
}
</STYLE>
WebFont objects are referenced by their name. The choice of WebFont name will affect the ability of user agent to employ host fonts. For maximum compatibility with host fonts, the name of the WebFont should be the name commonly known to the user, as reported by the standard APIs of the authoring system. To force the use of the WebFont definition (and preclude the use of host fonts) a unique name unrelated to the actual font name (e.g. "My Custom Font") may be given. When generating unique font names, authoring tools are encouraged to use techniques that tend to ensure uniqueness, such as a hash of certain font values.
Charater set sub-set information should not be included in the font name unless the intention is to specifically disable the use of host fonts. The use of distinct URLs (which may or may not include sub-set information) will be sufficient to prevent inadvertent loading of server fonts, while font description objects provide the sub-set information required by synthesis techniques.
WebFont objects are selected using either the style properties of font-family or font-face, or the <FONT FACE="font name"> tag. A WebFont may declare a single style and weight of a font, or a family. When a WebFont declaration specifies a family of fonts, the associated resource (for example, the server font) should provide all the weights and styles required by the document. As the actual usage in any given instance will be under the control of the document creator, the end result will always be deterministic.
To ensure accurate comparisons between font names, it is recommended that font names be converted to Unicode encoding prior to comparing. This will reduce unecessary references to server fonts or synthesis/substitution of local fonts.
Server fonts are specified by referencing the URL(s) where the font data can be found. This data can then be used by the user agent in rendering the HTML document. If multiple URLs are specified in the server font reference, then the WebFont is realized by combining the data from them all.
A given URL may be referenced by more than one WebFont declaration. This provides a mechanism for reducing the number of HTTP connections necessary to load the font data by combining multiple font resources into a single file. User agents should be aware of this and load the requested URL only once.
When using server fonts, users may wish to take advantage of character set sub-setting in order to reduce the amount of font data to be transmitted. To be most effective, sub-setting must be performed on a document by document basis. Since a given style sheet may be referenced by more than one document, a method is needed for converting a generic server font reference to a document specific font resource.
When specifying server fonts, the WebFont defintion may include the special identifier "@doc" which will be replaced by the name of the referencing HTML file minus the trailing ".htm" or ".html". For example, the reference
src: "@doc.ttc"
in a WebFont definition refenced by a document located at www.myserver.com/mypage/mydoc.html would be translated to
src: "mydoc.ttc"
and would refer to the server font at www.myserver.com/mypage/mydoc.ttc and when referenced by another document located at www.myserver.com/mypage/myotherdoc.html would be translated to
src: "myotherdoc.ttc"
and would refer to the server font at www.myserver.com/mypage/myotherdoc.ttc
Similarly,
src: "../fonts/@doc.fon"
in a WebFont definition refenced by a document located at www.anotherserver.com/webpages/webdoc.html would be translated to
src: "../fonts/webdoc.fon"
and would refer to the server font at www.anotherserver.com/fonts/webdoc.fon
Font Security and Intellectual Property
Font resources referenced via the server font mechanism will commonly contain copyrighted intellectual property. It is important that the property rights associated with the font resource be protected. The use of signatures or certificates is not sufficient as these can be forged, and only guarantee the identity of the originator. Server font transport and caching mechanisms should include security features (such as encryption) to ensure the protection of intellectual property. Additionally, retrieval of font data from caches must be performed via URL match, not font name match, as only the publisher of the font resource has the legal right to utilize it.
Within TrueType fonts there is a data item called "fs-type" which is used to indicate four levels of usage for the font. They indicate embeddable status, and target installation options and editing options. TrueType fonts that do not have the flag set to allow legal embedding should not be used in server font defintions, and should be ignored by both authoring tools and user agents.
Furthur discussion of encryption, hashing algorithms, expansion of "fs-type" mechanisms, and protection of cached font data is required. Suggestions in this area are welcomed.
Within the computing industry, there exist multiple formats for font data. While future developments may work to provide greater interoperability of these formats, it will be necessary for user agents (particularly those operating in legacy environments) to distinguish between different font types. Though basic differentiation between data formats could be accomplished via the "application" MIME type, font data is fundamentally different than the existing media types.
A new MIME type, named "font" with initial sub-types of "opentype", "truetype", "truetypegx", "type1", and "truedoc" is proposed. (Note that because of incompatibilities between the the implementations on some of these types on different platforms, it may be necessary to futher divide the sub-types list.)
This implementation will assist browsers in determining what resources they are capable of processing and in performing content negotiation. Non-graphical browsers can simply ignore font data (or request it only for printing), while other clients can negotiate the format best for them.
Authors may wish to provide information for either font synthesis or font substitution. This may be accomplished by defining font objects within an HTML document and referencing them from within the WebFont definition.
Font objects are declared using the <OBJECT> tag (see "Inserting objects into HTML"[Ref4]). By using an OBJECT structure within a document, character set sub-sets can be optimized for that document (similarly to with server fonts) to improve rendering performance even though a single style sheet is used for multiple documents. The <OBJECT> tag mechanism also provdes a flexible mechanism for implementing new synthesis and substitution technologies into HTML documents without requiring any revision of the WebFont specification.
OBJECT tags for use with font descriptions include the following attributes:
Font synthesis and matching technologies require parametric information about the original font in order to assure the highest quality results. This information can be supplied via either <PARAM> tags or the inclusion of a DATA attribute in the <OBJECT> tag (as shown in the examples below). The example parameters described below are not provided as an absolute specification of the parameters required for font synthesis or matching, but as an overview of the types of data that authoring tools and user agents will need to handle to provide these features.
The actual parameters required will vary depending on the technology employed by the object, but most implementations will typically require the following information to be able to approximate the appearance of the original font:
Font matching systems generally require one or more font description parameters to determine what available fonts are closest in appearance to the original font. The most common font matching scheme is PANOSE, which is based on either a 10 or 20 digit encoding of font attributes. Parameters for this technology might be:
Synthesizing a font means matching the width metrics of the specified font. Therefore, for synthesis, this metric information must be available. Similarly, progressive rendering requires width metrics in order to avoid re-layout of the content when the actual font has been loaded.
The following parameters are typcial of those required by font sysnthesis algorithms. Of these parameters, the most important are subsetchars (if the font is a subset), a widths parameter (one of widths, widths1, or widths2, and optionally one of defaultwidth or defaultwidth2) , and bbox which are used to prevent text reflow should the actual font becomes available. In addition, the parameters used for matching can be used to provide a better synthesis of the actual font appearance.
Example 1: Font synthesis object using <PARAM> tags for data passing:
<OBJECT DECLARE ID=CXFYTI+Tekton
TYPE="application/x-adobemm"
CLASSID="http://www.myserver.com/mydirectory/webfont.ocx"
>
<PARAM NAME="unitsperem" VALUE="1000">
<PARAM NAME="subsetchars" VALUE="MiTrnsch& ">
<PARAM NAME="widths" VALUE="658,689,647,482,482,482,482,482,482,447">
<PARAM NAME="stemv" VALUE="88">
<PARAM NAME="italicangle" VALUE="0">
<PARAM NAME="capheight" VALUE="673">
<PARAM NAME="xheight" VALUE="483">
<PARAM NAME="ascent" VALUE="709">
<PARAM NAME="descent" VALUE="-208">
<PARAM NAME="bbox" VALUE="-91,-309,1000,939">
</OBJECT>
Example 2: Font matching object using <PARAM> tags for data passing:
</OBJECT>
<OBJECT DECLARE ID=TimesPanoseData
TYPE="application/x-panose"
CLASSID="http://www.myserver.com/mydirectory/panose.stm"
>
<PARAM NAME="panose1" VALUE="02 02 03 00 00 00 00 00 00 00">
</OBJECT>
Example 3: Font synthesis object using the DATA attribute for data passing:
<OBJECT DECLARE ID=ArialGX
TYPE="application/x-truetypegx"
CLASSID="http://www.myserver.com/mydirectory/ttgx.stm"
DATA="www.myserver.com/mydirectory/fonts/arialdata"
>
</OBJECT>
The fontdef class would be used to define a font for referencing in any documents to which the style sheet applies, either as a style property or a direct font reference. The font "My Font" is defined and referenced in the example below.
<HTML>
<HEAD>
<STYLE>
@fontdef "My Font" {
src: fonts/subset_myfont.cff;
}
H1 {font-face:My Font}
</STYLE>
</HEAD>
<BODY>
<H1> This is displayed using My Font</H1>
<P><FONT FACE="My Font">This is also in My
Font</FONT></P>
</BODY>
</HTML>
The following examples will serve to illustrate the flexibility of the @fontdef approach.
<OBJECT DECLARE ID=CXFYTI+Tekton
TYPE="application/x-webfont"
CLASSID="http://www.myserver.com/mydirectory/webfont.stm"
>
<PARAM NAME="subsetchars" VALUE="MiTrnsch& ">
<PARAM NAME="widths" VALUE="658,689,647,482,482,482,482,482,482,447">
<PARAM NAME="stemv" VALUE="88">
<PARAM NAME="italicangle" VALUE="0">
<PARAM NAME="capheight" VALUE="673">
<PARAM NAME="xheight" VALUE="483">
<PARAM NAME="ascent" VALUE="709">
<PARAM NAME="descent" VALUE="-208">
<PARAM NAME="bbox" VALUE="-91,-309,1000,939">
</OBJECT>
<DIV @fontdef "Tekton" {
src: "Fonts/CXFYTI+Tekton.cff";
unicode-range:"0x80000000000000000000000000000000";
prog: "CXFYTI+Tekton";
desc: "CXFYTI+Tekton";
}
>
<FONT FACE=Tekton>Tin chins</FONT>
</DIV>
A font definition, some style specification, and some font and style references. Both font substitution and font synthesis data are supplied. The font synthesis data is contained in a file on the web server.
<HTML>
<HEAD>
<STYLE>
@fontdef "Tekton" {
src: "Fonts/CXFYTI+Tekton.cff";
desc: "CXFYTI+Tekton","TektonPanose";
}
@fontdef "Tom's new font" {
src: "Fonts/TomFont.ttf"
type: "font/truetype";
}
P {
font-face: Minion-SemiboldSC;
font-family: Minion;
font-weight: demi-bold;
font-style: small-caps }
.fancy {
font-face: CXFYTI+Tekton }
.special {
font-face: "Tom's new font";
}
</STYLE>
</HEAD>
<BODY>
<OBJECT DECLARE ID=CXFYTI+Tekton
TYPE="application/x-webfont"
CLASSID="http://www.myserver.com/mydirectory/webfont.stm"
DATA="www.myserver.com/mydirectory/fonts/CXFYTI+Tekton"
>
</OBJECT>
<OBJECT DECLARE ID=TektonPanoseData
TYPE="application/x-panose"
CLASSID="http://www.myserver.com/mydirectory/panose.stm"
>
<PARAM NAME="panose1" VALUE="02 02 03 00 00 00 00 00 00 00">
</OBJECT>
<H1 CLASS=fancy>Tin chins</H1>
<P STYLE="font-size: 24pt">
With full WebFont support, this is in 24 point
Minion Semibold Small Caps.
<FONT FACE="Tom's New Font">Special for Tom.</FONT>
</BODY>
</HTML>
A font definition where multiple URLs are referenced and combined to realize the font resource:
@fontdef "Bank Gothic LT" {
src: "fonts/basefont.pfb","fonts/page2.pfb","fonts/special.pfb";
type: "font/type1";
}
An example of font declarations using a URL which contains data for more than one font. In this case the user agent need only transfer a single server font resource to access the fonts.
@fontdef "Zurich BT" {
src: "www.bitstream.com/webpages/fonts/page1.ttc";
type: "font/truetype";
}
@fontdef "Zurich Blk BT" {
src: "www.bitstream.com/webpages/fonts/page1.ttc";
type: "font/truetype";
}
@fontdef "Map Symbols" {
src: "www.bitstream.com/webpages/fonts/page1.ttc";
type: "font/truetype";
}
An example showing a server font provided in multiple data formats which the data for one format being spread over multiple files.
@fontdef "BankGothic Lt BT" {
src: "fonts/bankgoth.ttf";
type: "font/truetype";
src: "fonts/basefont.pfr","fonts/page2.pfr","fonts/special.pfr";
type: "font/truedoc";
src: "fonts/bankgoth.t1";
type: "font/type1";
}
[1] T. Berners-Lee, D. Connolly, "Hypertext Markup Language - 2.0",
MIT/W3C, September 22, 1995.
<http://www.w3.org/pub/WWW/MarkUp/html-spec/html-spec_toc.html>
[2] Sandia National Laboratories, "HTML Elements List", 7 December
1995. <http://www.sandia.gov/sci_compute/elements.html>
[3] T. Berners-Lee, D. Raggett, "Giving Information About Other
Resources in HTML", Work in progress, W3C, 20 November 1995.
<http://www.w3.org/pub/WWW/MarkUp/Resource/Specification>
[4] D. Raggett, C. Kindel, L. Montulli, E. Sink, W. Gramlich,
J. Hirschman, T. Berners-Lee, D. Connolly, "Inserting objects
into HTML", Work in progress, W3C, 22 April 1996.
<http://www.w3.org/pub/WWW/TR/WD-object.html>
[5] Paul Haeberli, "WebFonts Proposal", Silicon Graphics, version
0.16. <http://reality.sgi.com/grafica/webfonts>
[6] Hakon W Lie and Bert Bos, "Cascading Style Sheets, level 1",
Work in progress, W3C, 5 May 1996.
<http://www.w3.org/pub/WWW/TR/WD-css1.html>
[7] F. Yergeau, G. Nicol, G. Adams, and M. Duerst,
"Internationalization of the Hypertext Markup Language", Work
in progress (draft-ietf-html-i18n-03.txt), 13 February 1996.
<http://ds.internic.net/internet-drafts/draft-ietf-html-i18n-03.txt>
[8] Adobe System, Incorporated, "Portable Document Format Reference
Manual Version 1.1", 29 April 1996.
<http://www.adobe.com/supportservice/devrelations/PDFS/TN/PDFSPEC.PDF>
[10] Adobe System, Incorporated, "PostScript Language Reference
Manual, Second Edition", Addison-Wesley, 1990, ISBN 0-201-18127-4.
[11] Microsoft Corp., "TrueType 1.0 Font Files", Revision 1.66, November
1995. <http://www.microsoft.com/truetype/tt/tt.htm>
[12] Adobe Systems Incorporated, "Adobe Type 1 Font Format
Supplement", Adobe Developer Support Technical Note 5015.
<http://www.adobe.com/supportservice/devrelations/PDFS/TN/5015.Type1_Supp.pdf>
[13] B. Bos, D. Raggett, H. Lie, "HTML3 and Style Sheets", Work in
progress, W3C, 19 January 1996.
<http://www.w3.org/pub/WWW/TR/WD-style.html>
[14] Microsoft Corp., "Microsoft Internet Explorer HTML Support", 1996.
<http://www.microsoft.com/ie/author/htmlspec/html_toc.htm>
[15] Microsoft Corp., "Microsoft Internet Explorer 3.0 HTML Support".
1996, <http://www.microsoft.com/ie/author/html30/html_toc.htm>
[16] Netscape Communications Corp., "EXTENSIONS TO HTML 2.0", 1996.
<http://www.netscape.com/assist/net_sites/html_extensions.html>
[17] Netscape Communications Corp., "EXTENSIONS TO HTML 3.0", 1996.
<http://www.netscape.com/assist/net_sites/html_extensions_3.html>
[18] S. Zilles, "Quality Printing on the Web", Adobe System, Inc., 23
April 1996. <http://www.w3.org/pub/WWW/Printing/zilles.html>
[19] Electronic Text Center, University of Virginia,
"Part I, section 2: A Gentle Introduction to SGML", P3.
<http://etext.virginia.edu/tei-tocs1.html>
[20] World Wide Web Consortium, "HTML 3.2 Features at a Glance",
7 May 1996. <http://www.w3.org/pub/WWW/MarkUp/Wilbur>
[21] B. Chase, "Towards Quality Printing of Web Documents", Bitstream Inc.,
April 1996. <http://www.w3.org/pub/WWW/Printing/chase.html>
[22] B. Bauermeister, "Font Delivery for HTML Documents", Hewlett Packard Co.,
16 April 1996. <http://www.w3.org/pub/WWW/Printing/bauermeister.html>
[23] R. Stevahn, "PANOSE: An Ideal Typeface Matching System for the Web",
Hewlett Packard Co., 22 April 1996.
<http://www.w3.org/pub/WWW/Printing/stevahn.html>
[24] H. Lie, "How to reference fonts from HTML", 7 July 1996.
<http://www.w3.org/pub/WWW/Fonts/Group/hwl-960707.html>
[25] World Wide Web Consortium, "Fonts for the Web: Rationale", 1 July 1996.
<http://www.w3.org/pub/WWW/Fonts/Group/WD-font-rationale-960701.html>