This is (soon to be) a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR/
Note: Since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
The goal of the W3C working group on fonts is to produce recommendations for open font solutions for the web. Issues to be resolved include, but are not limited to: style sheet notation, client-server request structure, font matching and synthesis information, and font location.
This document describes the goals of the W3C Font Working Group so that the design philosophy is clear. It includes examples of different scenarios where fonts might be used on the Web, and also has a glossary of terms.
Another document describes the abstract information needed to describe fonts for matching, synthesis, or requesting a font over the Web. A third document binds font descriptions to HTML and CSS-1. Bindings to other media, for example to VRML, to CGM, or to Java, are also possible.
The following list of goals is not in order of importance. Each item is linked to a fuller description:
We should not require proprietary technology, and the solution must not be restricted to a single or limited number of technologies. We do not know what file formats or compression schemes will be used, and cannot predict all font technologies that might exist in the future.
Thus, a solution for Fonts on the Web should be a framework, capable of supporting current and future technologies (based on content negotiation between a knowing and willing sender and recipient), and be implementable from publically available specifications.
Although the initial focus of our work is the use of Fonts in HTML, the solutions should be sufficiently general that other media can re-use relevant parts of our specifications. Ideally, if a particular web font was requested by an HTML document, should be re-usable by (say) a Java applet which calls for the same font, without having to fetch it again.
We plan to work fast, producing specifications before versions of browsers are released that incorporate the new font capabiliites. The first rough draft to be available in early July, with a stable draft by early August (ready, perhaps, for public exposure on the W3C TR list at this point?) Of course the work does not stop there; test implementations and proofs of concept are needed, the specifications get polished and dis-ambiguated; we issue press releases; the drafts move through to publication, the final versions are implemented in browsers and authoring tools.
Increasingly, documents are automatically generated. It should be possible for multiple independent scripts to each generate (parts of) an HTML document which uses Web Fonts, without requiring random access editing at the time of document generation; simple concatenation should suffice.
It should be possible to reference fonts whose lifetime and accessibility is limited to the displayed document. It the fonts have names, these should not match any fonts installed on the client.
There was agreement on the desirability of mechanisms for enabling fair play on Intelectual Property Rights issues. This was seen as a first step, and preferably to promising cast-iron protection against theft which it was noted would require strong encryption technology.
It should be possible to avoid getting the same font multiple times (in particular, the same font should not need to be obtained on each repeated download of the same document). This benefits individual users, in that they see the completed document quicker; it also benefits the net as a whole by minimising total bandwidth use. The aim is to be cache freindly, and also to be replication-freindly.
Latency may be reduced by progressive rendering, and may also be reduced at the user's option by disabling downloading of Web Fonts (in the same way that may browsers permit disabling of inline image downloading).
Provide the means so that authors who want it, and browsers that support it, can add the data needed for progressive layout whereby the font is rapidly synthesised during font data download, and the line breaks don't change when the real font comes in. It was noted that tables of glyph widths provide no help with kerning, so lines (especially headlines) will get shorter once the real fonts arrive.
Fonts should be referenced by name, for example "Tekton" rather than by some meaningless identifier, for example "84fvo325z2356". This raises the issue of exactly what is mean by a font. The font name should reference a single font file, not a styled family of four (unless of course, we can come up with a common scheme that works across platforms. It seems that we mean a particular face of a font, or some subset of it, for example "Bodoni Medium Italic". This may mean a font collection, for example latin, cyrillic and greek glyphs in three font files, forming a single face of a multilingual font; or two font files, latin characters plus small-caps and old style figures, forming a complete glyph repertoire of a single font face.
This reduces down to having a URL for a font face resource.
Strongly tied to progressive rendering, but more a strategy for situations where the font data cannot be fetched over the net. Where supplied by the document author, font description and metrics should be able to drive font synthesis (Infinifont, Chameleon, etc.) and substitution (PANOSE) engines.
The proposed solution must be independent of font platform, browser platform and media type (Page Description Language). This is clearly needed - click here for the mac version, yeuck!
Currently all quality typography on the Web uses inline images. If sending an image is smaller, faster, causes less platform headaches, and is devoid of IPR issues, then our solution will go unused. We should support as many standard typographic features as we can. While we probably cannot eliminate all usage of images to fake text - there is always one more effect - we can sure go for the 80/20 rule so that the font solution becomes the norm.
Authors should own the fonts and browsers should protect IPR. New purchases should not be required, in that font purchases in existing formats should be usable provided the license permits such use; but our solution need not eliminate the need for new purchases either. Users should be able to use their own installed fonts (at least when using font substitution). The time and effort neccessary to extract new fields from existing font files should be kept to a minimum.
An HTML document is a marked-up sequence of characters. It is not a list of indexes into a font. HTML remains character-, not glyph-oriented. Thus, ligatures and contextual forms will be left to the type technologies (such as OpenType), rather than supported via our Web font descriptors.
For many European languages, there is in most cases a one-to-one maping between characters and glyphs; so this distinction is only seen when, for example, someone inserts a code for an 'fl' ligature (and then discovers that the search engines are unable to index the document correctly). This has particular implications for scripts such as Arabic, which has four different glyphs for each character even without taking into account the ligatures required.
This also implies that some other data may be needed (the lang attribute in HTML is an obvious example). It has implications when glyph subsets of a font are requested.