The CSS 1 [Ref 6] style sheet mechanism provides a way to reference fonts either directly or implicitly by assembling a set of properties that select a suitable font. This specification extends CSS to add a "font-face" at-rule. This at-rule defines font face names and provides for defining, either by reference to a URL or within an HTML document, the properties associated with that face name and the source of the data necessary to render the glyphs in that font.
Increasingly, HTML documents [Ref 1] that use a wide range of typographic fonts have been authored and distributed on the web. Today, this works as long as the recipient of the document has all the fonts used. But, because there is an very large collection of possible fonts that could be used, it is not reasonable to assume that all users of a given document will have always have all the fonts used in that document. It is, therefore, important that the mechanism for specifing and referencing fonts (a) support fonts provided on the Web site serving the document and (b) do so in a way that will delay the display documents as little as possible.
The purpose of the font definition is to provide the information needed either (a) to select a font from the collection of fonts known to the platform or user agent, (b) to access a font provided over the Web, or (c) to substitute or synthesize a replacement font. For information on the overall structure and rationale for handling fonts see Fonts for the Web: Rationale [Ref 22].
The font definition provides the bridge between a font reference within an HTML document and the actual font data. The font data is the data needed to format text and to render the glyphs to which the formatted characters map. Fonts may be referenced either by stylesheet attributes or by explicit name. In either case, the font definition is used either to find the relevant font data or to find a substitute font to use. The font defintion provides both the location of the font data on the Web and a set of font properties that characterize that font data. The font properties are needed both to match the stylesheet font properties to particular font data and to help select a substitute font when the specified font data is not accessible.
There are three basic parts to a font definition: (1) the font face name which names the font definition, (2) the URL for the source of the font data for the font and (3) the set of font properties that characterize the font. The font properties may either be within the font definition within the document or may be provided within a separate font definition resource identified by a URL. Because the font properties are separate from the font data and may have less restrictive protection requirements,
Having the font properties separate from the font data has a benefit beyond being able to do font selection and/or substitution. The data protection and replication restrictions on the font properties may be much weaker than on the full font data. Thus, it may be possible to locally install the font definition. This would allow the abbreviated form of font definition within documents, but would not require accessing the full font definition over the Web more than one time per named font.
Access to locally stored information would be via the font face name. The font face name is not a truly unique, but it is the best way, extent today, to identify font data. The use of the font face name can be made more accurate by providing an indication of the glyph complement required. The ulUnicodeRange bits in the OS/2 table of TrueType and OpenType fonts provides a way to indicate the glyph complement requirements.
There are two ways to provide a substitute font when the requested font is not accessible: matching or synthesizing. Matching involves using an existing, accessible font that is the closest match in appearance to the requested font (note that the metrics might not match). Synthesizing involves creating a font which is not only a close match in appearance, but also matches the metrics of the requested font.
Synthesis information also enables progressive rendering. Progressive rendering is process of faking or fauxing a specified font so that the text in that font can be displayed while awaiting the arrival of the specified font data from a server. The faux font is created by blending a substitute font, which approximates the look of specified font, to match the metrics and weight of the original font, Progressive rendering requires metric information about the font in order to avoid re-layout of the content when the actual font has been loaded.
The name of the font definition is important because it is the link to any locally installed fonts. It is important that the name be robust, both with respect to platform and application independence. For this reason, the name should be one which is not application or language specific.
The ideal solution would be to have a name which uniquely identifies each collection of font data. This name does not exist in current practice for font data. Fonts with the same face name can vary over of number of properties. Some of these properties, such as different complements of glyphs in the font may be insignificant if the needed glyphs are in the font. Other properties, such as different width metrics, make fonts with the same name incompatible. It does not seem possible to define a rule that will always identify incompatibilities, but will not prevent the use of a perfectly suitable local copy of the font data with a given name. Therefore, only the ulUnicodeRange property will be used to qualify matches for the font face name.
Since a prime goal of the font face name in the font definition is allow a user agent to determine when there is a local copy of the specified font data, the font face name must be a name which will be in all legitimate copies of the font data. Otherwise, unnecessary Web traffic may be generated due to missed matches for the local copy. Two such names are the PostScript language name in Type 1 and TrueType/OpenType fonts, and the "full font name" in TrueType fonts.
The PostScript language name of a font is the name which, in a PostScript language program, is used as an operand of the findfont operator. It is the name associated with the font by a definefont operation. This is usually the value of the FontName key in the PostScript language font dictionary of the font [Ref 8]. For more information, see Section 5.2 of the PostScript Language Reference Manual, Second Edition [Ref 10].
Multiple Master Type 1 fonts allow specifying various design dimensions (e.g., weight, such as light to extra-bold, and width, such as condensed to expanded) [Ref 12]. Coordinates along these design dimensions are specified by numbers, and are appended as a suffix to the base font name. To specify the appearance of the font, numeric values must be supplied for each design dimension of the multiple master font. A completely specified multiple master font is referred to as an instance of the multiple master font.
The PostScript language name used for a Multiple Master Type 1 is the name the instance. If the name contains spaces (such as "MinionMM 366 465 11"), these spaces are replaced with underscores. For example, the base font name here is TektonMM and the 2 dimensions specified have values of 200 and 300:
TektonMM_200_300
For TrueType fonts, the font face name used in the font definition is that specified by the full font name in a TrueType font file (from the name table) [Ref 11].
The full font name of the TrueType font and the PostScript Language name may differ by spacing and punctuation. For example, spaces are not allow in a PostScript Language name, but are common in full font names.
Font subsets should be named with the base font face name. The ulUnicodeRange property should be set to indicate the sets of glyphs complements from which the subset characters/glyphs come. Finally, the presence of the SubsetChars or SubsetGlyphs property will indicate the subset of glyphs that are required to render the document.
Style sheets provide a mechanism for associating formatting information with HTML documents. The CSS1, or "Cascading Style Sheets, level 1" [Ref 6] specification specifies style sheet syntax and "HTML3 and Style Sheets" [Ref 13] specifies ways of incorporating stylesheets into HTML.
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 defined in the CSS1 specification [Ref6].
This specification extends CSS1 to define a new "at-rule", @font-face, that is used to define a font that can be referenced with any documents to which the style sheet applies, either as a style property or a direct font reference.
The basic form of the new at-rule is "@font-face <face-name> ", where the the face-name is as described in the section on font naming above.
The font "My Font" is defined and referenced in the example below.
<HTML>
<HEAD>
<STYLE>
@font-face My Font {
src: fonts/embedded_myfont.ot;
…
}
H1 {font-face:My Font}
</STYLE>
</HEAD>
<BODY>
<H1> This is displayed using My Font</H1>
</BODY>
</HTML>
Another example is
@font-face Helvetica-Bold {
src: fonts/common13/Helvetica-Bold.ot
}
Font-face Properties
Font-face Properties That Are Required for Font
Data Qualification
The following properties are optional within a font definition,
but are required to insure that a local font that has a matching
font face name has sufficient glyphs to render the characters in
a document.
The following property is optional within a font definition, but are required to if there are any numeric values in the EM space in which glyphs are defined.
The following properties are optional within a font definition, but are required if the author desires to embed a font by reference.
The following property is optional for a WebFont definition, but is the properties can be used if font matching is desired by the author.
panose: 02 02 03 00 00 00 00 00 00 00;
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. Although the following properties are optional for a WebFont definition, some are required if synthesizing (and progressive rendering) is desired by the author. Should the actual font become available, the substitution should be replaced by the actual font. Any of these properties which are present will be used to provide a better approximation of the intended font.
Of these properties, the most important are subsetchars (if the font is a subset), a widths properties (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 properties in the set of properties required for matching can be used to provide a better synthesis of the actual font appearance. Any properties which are not recognized or useful to the user agent should be ignored. This allows adding in the future optional properties for the purpose of better font substitution.
subsetchars: "MiTrnschqpueo& ";
If the subsetchars property is present, the order of characters in the subsetchars implies the order of widths.
If no subsetchars property is present, the order of widths is the same as for code points for the font used in the HTML document. If the number of entries is less than required, missing entries default to that in defaultwidth (if present), or 0.
For example,
widths: "212,230,337,497,513,792,605,188,
284,284,415,596,207,307,207,343";
Any white space is ignored within the quoted string.
Another example: a subsetted font in a WebFont @font-face font definition containing a subsetchars properties
subsetchars: "MiTrnsch& "; widths: "658,689,647,482,482,482,482,482,482,447";
bbox="-206,-233,1006,896"
The widths1 property allows the definition of widths for single code or a range of codes. The entry is a comma-separated list in the following two formats:
c1, [w1, w2, w3] c2, c3, w4
In the first format, c1 is an number specifying a starting code value. It is followed by an array of numbers which specify the widths for code with values starting from c1 consecutively up to the end of the array. The second format defines the same width for codes in a range. In this format, c2 is the first code in the range and c3 is the last and they are followed by the width for all of the codes in the range.
Following is an example of a widths1 property.
widths1="120, [400, 325, 500],
7080, 8032, 1000"
In this example the codes 120, 121, and 122 have widths 400 325 and 500 units, respectively. The second list in this example specifies that codes between 7080 and 8032 inclusive have a width of 1000 units.
In vertical writing the character position is described by a position vector from the origin used for horizontal writing to the origin used for vertical writing. This new origin is called the writing mode 1 origin. The advance width is defined by a vector from the new origin to the writing mode 1 origin of the next character [Ref 10, pp 273].
The default position vector and vertical writing is specified by the defaultwidth2 property. This property specifies the y component of the position vector and the x and y components of the vertical width vector. The x value of the position vector is calculated from the horizontal width divided by two. For example if the defaultwidth2 entry is:
defaultwidth2: "880, 0, -1000";
the position vector and width vectors are:
v = (hw/2, 880) w = (0, -1000),
where hw is the horizontal advance width.
The default vertical width can be specified with the defaultwidth2 property. Glyphs that differ from the default vertical metrics must be included in the widths2 property. In this property, the position vector and advance width are defined by four numbers which give the x and y values of the two vectors. There are two formats that can be used to define these vectors as shown below:
widths2: "c1, [w1x, w1y, v1x, v1y,
w2x, w2y, v2x, v2y, ...],
c2, c3, w1x, w1y, v1x, v1y";
In the first entry, c1 gives a starting code and is followed by an array. The array contains sets of four numbers which define the x and y values for the vertical advance width followed by the x and y values for the position vector. The sets of four numbers define the vertical metrics for consecutive character codes starting with code value c1. The second format defines a range of codes from from c2 to c3. These ranges use the same format as defined for the widths1 array. The range is followed by four numbers which define the vertical metrics for all codes in the range.
Following is an example of a widths2 entry.
widths2: "120, [0, -1000, 250, 772],
7080, 8032, 0, -1000, 500, 900";
This entry defines the width for character code 120 as (0,-1000) and the position vector as (250, 772). The second list in the array defines the width to be (0,-1000) and the position vector of (500, 900) for the range of codes between 7080 and 8032 inclusive.
unitsPerEM: 1000;
stemv: 88;
bbox: "-206,-233,1006,896";
italicangle: 0;
capheight: 673;
xheight: 483;
ascent: 709;
descent: -208;
panose: "02 02 03 00 00 00 00 00 00 00";
widths: "250,212,318,592,496,592,591,146,
345,345,369,554,208,348,208,322,627,299,539,587,
564,569,642,480,629,600,208,208,554,554,554,412,
786,630,613,539,608,560,519,715,626,220,520,560,
465,755,612,596,543,617,577,626,466,579,495,692,
441,560,510,341,322,341,554,500,263,512,463,456,
513,444,315,476,479,200,221,409,200,728,479,476,
482,498,362,491,438,480,390,560,397,432,431,347,
200,347,554,396,396,396,167,499,333,1000,449,
449,351,863,626,279,908,396,396,396,396,167,167,
333,333,396,500,1000,440,764,491,279,742,396,
396,560,250,212,474,617,498,594,204,577,329,786,
403,452,554,348,786,361,241,554,370,403,219,480,
500,208,330,207,403,452,731,747,877,412,630,630,
630,630,630,630,794,539,560,560,560,560,220,220,
220,220,608,612,596,596,596,596,596,554,596,579,
579,579,579,560,533,569,512,512,512,512,512,512,
763,456,444,444,444,444,200,200,200,200,485,479,
476,476,476,476,476,554,476,480,480,480,480,432,
482,432";
Font Definitions are referenced from HTML documents via stylesheet properties [Ref21]. These properties may explicitly select a font face name or may combine to select a font definition whoses properties best match the properties specified by the stylesheet [Ref6] and [Ref13]. specifies ways of incorporating stylesheets into HTML.
<DIV @font-face Tekton {
src: "Fonts/subsetTekton.ot"
ulUnicodeRange: "0x80000000 00000000 00000000 00000000";
unitsPerEM: 1000;
subsetchars: "MiTrnsch& ";
widths: "658,689,647,482,482,482,482,482,482,447";
stemv: 88;
italicangle: 0;
capheight: 673;
xheight: 483;
ascent: 709;
descent: -208;
bbox: "-91,-309,1000,939"
}
>
A font definition, some style specification, and some font and style
references:
<HTML>
<HEAD>
<STYLE>
@font-face Tekton {
src: "Fonts/subsetTekton.ot";
unitsPerEM: 1000;
subsetchars: "MiTrnsch& ";
widths: "658,689,647,482,482,482,482,482,482,447";
stemv: 88;
italicangle: 0;
capheight: 673;
xheight: 483;
ascent: 709;
descent: -208;
bbox: "-91,-309,1000,939";
signature: "[not yet specified]";
}
@font-face New font of Tom {
src: "Fonts/TomFont.cff"
}
P {
font-face: Minion-SemiboldSC;
font-family: Minion;
font-weight: demi-bold;
font-style: small-caps }
.fancy {
font-face: Tekton }
.special {
font-face: "New font of Tom";
}
</STYLE>
</HEAD>
<BODY>
<H1 CLASS=fancy>Tin chins</H1>
<P STYLE="font-size: 24pt">
With full WebFont support, this is in 24 point
Minion Semibold Small Caps.
<SPAN STYLE="font-face: New font of Tom">Special for Tom.</SPAN>
</BODY>
</HTML>
[1] T. Berners-Lee, D. Connolly, "Hypertext
Markup Language - 2.0",
MIT/W3C, September 22, 1995.
<htt
p://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://ww
w.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/gr
afica/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/W
WW/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.
&l
t;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.Ty
pe1_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://w
ww.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.
<htt
p://www.netscape.com/assist/net_sites/html_extensions.html>
[17] Netscape Communications Corp., "EXTENSIONS
TO HTML 3.0", 1996.
<h
ttp://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.ed
u/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] World Wide Web Consortium, "WebFonts: how to
reference fonts from HTML",
8 July 1996. <http://www.
w3.org/pub/WWW/Fonts/Group/hwl-960707.html
[22] World Wide Web Consortium, "Fonts for the
Web: Rationale"
1 July 1996. &
lt;http://www.w3.org/pub/WWW/Fonts/Group/WD-font-rationale-960701.html