Activity statements provide a managerial overview of W3C's work in each area, covering: an introduction to the activity, the goals of W3C work, the accomplishments to date, and future plans. They are designed to be read from beginning to end, to be informative and interesting. The introductory section serves to set the scene and to explain any technical concepts used in subsequent sections. Where necessary the explanation is expanded into a short tutorial. The role of W3C is given, also the benefits to the Web community, accomplishments to date and a summary of what the future holds.
Work on Web Fonts is being managed as part of W3C's User Interface domain.
HTML, and applications of XML, describe the logical structure of a document. The rendering of HTML is often browser-specific, although style sheets allow both the document author and the reader to influence presentation, using a common format. There are no default conventions for XML documents, which rely on style sheets for presentation. CSS1 stylesheets reference Font names, often assumed to be available to the client. However there are thousands of Fonts, so clearly not all Fonts are available on all systems.
There needed to be a way for the referenced Fonts to be obtained over the Web. W3C therefore started an activity area to examine how to provide Fonts on the Web.
Designers like to use different Fonts to give a particular look and feel to a site, or to a page. The issue here is the diversity of different glyphs (arranged in different Fonts) for the same characters, to provide typographic diversity or to fit a corporate image.
Multi-lingual documents require Font support for rendering characters which are not local to the client. For example, Arabic characters in a European-localized browser, or Latin (European) characters in a Cyrillic-localized browser. The issue here is the diversity of different characters in the many languages of the world; each character requires at least one glyph to be available so that it does not display as a white box, or something.
Web Fonts can be used in CSS2 style sheets, or in other style sheet notations. Other media need Web Fonts, too. Java applets, for example, or VRML scenes, or inline CGM. The Web Font solution is reusable by these other media.
To make Fonts work on the Web, we needed:
One or more open, platform-independent Font specifications which describe how Fonts can be stored in a manner suitable for being downloaded over the Internet and used on multiple platforms. Platform-specific assumptions (such as the encoding vector, byte order, and so on) should be avoided in such a format; rather, they should be stated explicitly in the file, or defined by the format. OpenType and TrueDoc have been used by the initial implementations.
Scalable outline formats, which can be rendered at different text sizes and at different display densities, are preferable, but bitmapped fonts are also catered for. Web Fonts does not limit the formats, since a new and better ones might arise. A single font description can reference multiple font formats, permitting the use of different browsers or platforms.
Some Fonts, available in one or more of those formats, which site designers could use in their documents. Some of these should be free, others may well require payment (by the site designer, or by the reader). At least one freely available Font, that provides glyphs for rendering all the Unicode characters, sounds like a good idea although the vast majority of the glyphs in such a font would be Han ideographs. Greater typographic quality for typical pages which only contain writing in a small number of scripts can be achieved with fonts which cover a smaller range, or a composite font consisting of several base fonts designed to work well together.
Fonts that require the reader to pay (perhaps using micro-payments) are technically possible but are likely to have a slower uptake than Fonts which do not use a pay-per-view model. More likely is that the site pays licensing fees, and the font is constrained to be usable only from that site. Both of the font formats mentioned above restrict font usage to the original site in this way.
A way to specify such a Font, including a URL, so as to that permit:
Web Fonts uses a set of font descriptors which cover all these requirements and also optionally provide information useful for intelligent matching of fonts on the client, and for font synthesis on the client.
A clear and machine-readable Font licensing model, which recognizes that Fonts are increasingly used online as well as on paper, and permits such deployment while respecting the copyright status of the Font programs and the name of the Font. Over the last few months, font licenses from some foundries have been modified to take into account Web Fonts. In some cases explicit permission is given to use the fonts on the Web, in other cases, such use is specifically denied.
Code-signing, encrypted URLs (limiting the sites which may reference the fonts) and digital signatures on machine-readable assertions might also be useful for protection of Intellectual Property Rights. The W3C Digital Signatures specification looks helpful in this regard, and could be used to sign RDF assertions to produce machine-readable font licenses.
A fallback method when the requested Font is not available - all the servers are down, or it costs money to download, or the reader has chosen to browse with Font downloading disabled (as image downloading can be disabled now) on a low bandwidth line, for example. This can involve selecting an installed Font with similar characteristics, or synthesizing a new Font that imitates the unavailable one. The Web Font specification describes how both of these fallback methods can be used to increase robustness and display speed.
Any font solution which did not address the needs of Internationalization would be very short-sighted. W3C strove to design a Web Font solution such that Internationalization was aided, or at very least not hindered. The specification caters for different baselines, as used by Ideographic or Indic scripts, and copes with bidirectional text for Hebrew and Arabic; it does not currently have descriptors for fonts used for vertical writing.
The W3C Cascading Style Sheets and Formatting Properties Working Group used earlier work to design complete the Web Fonts specification, in particular for use in CSS2.
CSS1 already allows control over fonts, but requires that they are installed using the same name on the client system.CSS2 allows intelligent matching (based on font properties rather than just name), client-side font synthesis, and font downloading. This extension does not mandate any particular font format, many formats can be used.
Things which W3C and it's member companies are working on or could produce include:
Browsers that implement client-side font synthesis
Fonts in one or more of the popular formats - including some free ones - covering a variety of scripts (such as Latin, Hebrew, Cyrillic, Greek and Arabic for example), with licenses which permit use on the Web.
More UA implementations, to promote rapid deployment of the adopted solutions.
More authoring tool support, both for generating the font descriptors and for creating the style sheet and document markup.
Current outstanding issues that require further resolution include:
MIME type registration of font formats for content negotiation
Use of digital signatures
Specification of behavior for one-to-many mappings of characters to glyphs (for example, contextual forms in Arabic and Hebrew) and when glyph rearrangement is required (for example, South Indian scripts such as Tamil). A spin-off from this Internationalization work will be richer features for Latin typography, such as control of swash characters and ligatures while retaining an HTML document which contains legible and indexable text.
Additional descriptors to aid intelligent matching and client side synthesis of cursive scripts such as Arabic, and of ideographic scripts such as Japanese.
Chris Lilley (chris@w3.org) is the Activity leader.