July 2, 1996
Adobe Systems, Inc. Randy Polen, polen@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).
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.
Goals of the working group are to provide a structure that allows for multiple font mechanisms, and provide a means to define future font mechanisms. The working group hopes that user agent and authoring tool providers implement the features that make sense for their market.
A variety of methods may be used for displaying (and printing) fonts in web documents. Among these are use of native fonts, font matching, font synthesis, and full font fidelity acheived through the access of server font resources. The primary goal of this document is to define a mechanism whereby the creators of authoring and viewing tools can implement these capabilities in a platform independent manner, and authors and users can employ them in the manner best suited to their needs.
Due to the nature of the Internet protocol, there is a concern about the number of connections that are used to negotiate for fonts. Implementations of fonts within HTML authoring or publishing tools that allow for poor performance are possible, however highly discouraged. It will be possible to define hundreds of font references using many character subsets that may be negotiated for a simple document, however the most efficient implementations usually carry higher commercial value. Font mechanisms that allow many fonts to be consolidated within one object will be more efficiently transported than individual objects.
Character subsetting must be a shared goal between the authoring tools and browser developers. Authoring tool providers should consider character subsetting of fonts because it one of the best means of reducing the size of fonts that may be moved from servers to clients. Browser developers should consider the possibility of merging multiple character subsets for the same font, font caching, and how long fonts persist in cache.
Font mechanisms that are provided in this draft will provide for better font controls, and thus provide for a better look and feel. The use of images (gifs, jpegs, ect.) that contain fonts in order to obtain the look and feel hopefully will subside as this standard is implemented. This method of using images has required thousands of hours of webmasters time, placed a heavy bandwidth burden upon the network, and often resulted in loss of important searchable content.
Exact page layout is not a goal of WebFonts or HTML due to the ability of end user to resize the window and have text reflow. There are plug-ins, helper apps, and java applets that can provide for almost exact page layout if desired.
Finally, developers realize that fonts are classified as software and are usually sold with a license. Therefore, protection of the data must be considered, especially if fonts are cached on disk.
WebFonts provide the ability to incorporate fonts in Web documents. This is done by allowing authors to define named font defnitions which can be referenced from within a style sheet using the font-family or proposed font-face properties. These font definitions can also be referenced using the popular non-standard HTML extension <FONT FACE=...>.
The actual font displayed when a document is viewed will depend on the the following factors:
Depending on which information is included with the WebFont definition and how the user agent is configured, the process of realizing a font definition will follow a certain sequence:
The order of use for font descriptions is specified by their order of reference in the desc or prog attributes of the WebFont.
Providing this tiered approach allows the content provider as well as the end user to control various aspects of how WebFonts are used, by indicating priorities for handling font functionality.
Content providers may choose to indicate the following font preferences:
The end user is ultimately in control of what font representations will be used. As is done for images, users can indicate (depending on user agent implementation) their preferences for:
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.
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. (Font defintions may also be selected using the <FONT FACE="font name"> mechanism.) The font name is case insensitive.
The following properties can be used within a webfont declaration:
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 (e.g. "My Custom Font") should be given.
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. As the actual usage in any given instance will be under the control of the document creator, the end result will always be deterministic.
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
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 must include security features (such as encryption) to ensure the protection of intellectual property.
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, similar to image data, what resources they are capable of processing and 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 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 associating the object with the document, different character set sub-sets optimized for each document may be used (similarly to with server fonts) to improve rendering performance even though a single style sheet is used for all.
The metric information required for progressive rendering or font matching can be supplied via either <PARAM> tags or the inclusion of a DATA attribute in the <OBJECT> tag as shown in the examples below:
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.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>
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";
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";
}
The FONT tag, part of HTML3.2 [Ref 20], is supported by the major browser vendors [Ref 14][Ref 15][Ref 16][Ref 17]. Another way to reference WebFonts is through the STYLE element and property.
The non-standard FACE= extentison to the FONT tag has gained general industry acceptance, and it's interaction with WebFonts must be clearly defined. WebFonts can work with the FONT element. The FACE property of the FONT tag can be used to select a font by name. The FACE name can be resolved in one of two ways. The examples above illustrate both ways.
The SIZE property can be used to set the size of the text. In addition to the existing relative (e.g., 1-7) size designations, absolute sizes in points (where 1 point equals approximately 1/72 of an inch), using "pt" as a suffix on the numeric size. For example:
SIZE=24pt
Once a WebFont is resolved, the CSS font-face property can be used to reference the font by name. A new property is needed since font-family is not the same as font-face.
<STYLE>
H1 {font-face:My Font}
</STYLE>
The name value can be either a name matching the face value of a prior font definition, or that of a font in the host system (these are the same rules as those for the FACE property in the FONT element). Additional font properties applied to resolved WebFonts are ignored.
If WebFonts are selected using FONT tag, there are some interactions to be specified. If WebFonts are selected using the STYLE mechanism, there are no unintended interactions with the existing HTML typograhic (or "font style") and idiomatic (or "phrase") elements.
WebFonts selected by the FACE property of the FONT element are quivalent to font-family specifications; the typographic elements of HTML 2.0 or HTML 3.2 may change the specified font but idiomatic elements do not.
In HTML 2.0, the idiomatic elements are CITE, CODE, EM, KBD, SAMP, STRONG, VAR. In HTML 3.2, DFN is added. The interaction between idioms and fonts selected by the FONT element is that the innermost element which selects a font is used to render the surrounded block of text.
In HTML 2.0, the typographic elements are B, I, TT. In HTML 3.2, STRIKE, BIG, SMALL, SUB, and SUP are added. The interaction between these typographic elements and the fonts selected by the FONT element is: if the FONT element has associated with it a valid font (based on the implementation at runtime), the typographic element is applied to the font (if possible), otherwise, the typographic element is used as in HTML 2.0 or HTML 3.2.
The following are some examples of these interactions.
The following fragment would render with the font associated with face=Tekton (assuming "Tekton" resolves to a valid font from a fontdef), regardless of any association made between a font and the emphasis element (EM):
I really <EM><FONT FACE=Tekton>love</FONT></EM> fonts!
Conversely, the following fragment would render with the font associated with the emphasis element:
I really <FONT FACE=Tekton><EM>love</EM></FONT> fonts!
In both of the following fragments, the order of elements is not considered. Each would either render with a bold version of the font associated with face=Tekton when a valid font is available (synthesized, downloaded, available on the system, etc.; that is, if the fontdef successfully caused the user agent to instantiate a font), or render in whatever manner the user agent would use to indicate bold text. In both cases, the rendering would be a bold version of the Tekton font.
<B><FONT FACE=Tekton>In the News: Web fonts announcement</FONT></B> <FONT FACE=Tekton><B>In the News: Web fonts announcement</B></FONT>
In order to bind WebFonts to CSS1, there is an additional font property.
See Font Names, above. For example,
H1 { font-family: "New Century Schoolbook";
font-weight: Bold;
font-style: Italic;
font-face: "New Century Schoolbook Bold Italic" }
The value can be either a name matching the <font name> value of a prior fontdef, or that of a font in the host system (this is the same rules as that of the FACE property in the FONT element).
The font-face property is used if provided; if not provided or does not resolve to a realized font, the font-family, font-weight, and font-style properties are used (if provided). Any conflicts or inconsistencies are ignored between the font-face property and the combination of properties font-family, font-weight, and font-style.
[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>