W3C wants to ensure that graphical web clients have the necessary font resources to make rich presentations in many languages. This document contains some of our ideas and information on this issue as well as relevant links.
What is needed is, amongst others,
There is also an issue of payment and copyright protection for fonts.
We have started an electronic mailing list to discuss issues related to fonts and the web. To subscribe to www-font, send the word subscribe to www-font-request@w3.org. You can also browse the archives.
http://www.unizh.ch/ps/truetype.html compares TrueType and Type 1.
There appear to be archives of TrueType fonts available.
However, there is a fall-back approach: send the fonts. Adobe is working with other major font vendors to modify the shrink-wrap font license to permit distribution for read-only or print-only use. Adobe will license this use for its own fonts, and the ITC (the licensing agency for a substantial fraction of everybody's font libraries) has agreed to do so as well. The other font houses will probably go along sooner or later.
(A third method -sending along the name of the font and its metrics- depends on a standardized naming scheme and presumes font-substitution smarts by a viewer at the other end. This method is being considered for ISO interchange formats.)
Several texts are apparently available on the WWW in TeX format http://www.loria.fr/tex/fontes.html
Metafont, rather than converting to a platform's local format, would run a local interpreter. It also has the advantage of a large library of free fonts, both general- and special-purpose, available on the Web. (See, for example http://jasper.ora.com/CTAN/tex-archive/macros/mtex/metafont/index.html). For those machines incapable of running Metafont (i.e., PDAs with little memory and/or computation power,) authors could provide pre-calculated scaled bitmaps for a few (low) resolutions.
The biggest problem with Metafont is that you cannot pull a single glyph definition out of it, send it across the net, and expect it to work. For very large fonts, sending individual glyphs will be necessary.
On the other hand, if a Metafont server rasterised the glyph, and sent back a bitmap, the problem goes away.
Each glyph is described as an outline built from straight lines and Bezier curves (cubic splines). At most 3 horizontal hints and 3 vertical hints per glyph can be set. A `hint' is region within which all curves should be rounded to fall exactly on the hint boundaries.
Font metrics are defined separate from the glyphs and allow kerning information, but no ligatures (?). A font can contain arbitrarily many glyphs, each of which has a unique name. A number of such names are standardized, but they are different from the names given in the Unicode character set.
Normally, (i.e., in a Postscript program) a font is accessed through an `encoding vector' that assigns a number from 0 to 255 to at most 256 of the glyphs in the font. The encoding vector can be changed on the fly.
Type 1 is capable of producing very high quality fonts, both for high resolution printers and low resolution screens, subject, of course, to the quality of the rasterizer and the hints. There is no provision for anti-aliased fonts (that has to be done solely by the rasterizer), not for multi-colored fonts. The speed of rasterizing is generally very good. Type 1 appears to be suitable for all glyphs, of all languages, including right-to-left and vertical ones.
Scalability only refers to linear scaling. Except for hints, which can modify the shapes at low resoultions, a glyph is scaled simply by multiplying all coordinates; thick/thin contrasts stay the same, horizontal and vertical parts are scaled by equal factors.
Specs are available on-line () and from ISO. Differences between the two are probably unimportant. Commercial rasterizers are available for most platforms, many are also built-in to printers and plotters. A low quality free rasterizer is available for most platforms in source form inside Ghostscript. There is also a rasterizer in source form distributed with X. Since X11R6 it is compiled into the core X library.
Hundreds (?), including all the common ones (Times, Helvetica, Computer Modern, Palatino, Courier, etc.) A few dozen (?) are free.
A typical font (with some 200 outlines in a single style) occupies 50-130 Kb. Partial downloads are not possible. Some compression is possible.
There is no software for creating original fonts in TrueDoc fonts directly. Instead, the TrueDoc encoder is given a bitmap of a particular glyph and fits its own curves to it. (The main purpose of TrueDoc seems to be to distribute fonts without infringing on copyrights; therefore it tries to record the shape, without using the original outline in TrueType, Type 1, etc.)
Each glyph is described as an outline, using cubic Bezier splines. Font metrics (escapements) are included, but only for individual glyphs, not for kerning. Ligature substitution is not recorded either. Hints are created by an auto-hinting algorithm that is built-in to the software that converts from other formats to TrueDoc. How many hints and of what type is not known. It doesn't seem possible to do manual hinting.
Kerning information can, however, be stored in an extension (`aux') area. The format for storing it there is currently application specific, but could probably be standardized.
No room for ligature information is foreseen, though it could in principle be added to the `aux' area, if Bitstream defined a format for it. Anti-aliasing must be done by the client-side renderer. There is no color information.
The glyphs aren't identified in any way, except by a number. There is no mapping to standard (Unicode) numbers or names, or Adobe glyph names. The application is supposed to know which character corresponds to which number. The numbers can be 16 bit quantities. External means (such as HTTP headers) are needed to tell the application which font encoding was used by the creator of the font. Another possibility is to use Unicode as the required format for all TrueDoc files sent over HTTP.
Font can be rendered to a maximum of 32K pixels square (or about 34cm on a 2400dpi typesetter).
The renderer is available for free from Bitstream, though not (yet?) on-line. The encoder that creates the TrueDoc files must be bought. The files are also referred to as PFR files (Portable Font Resource).
TrueDoc files are compressed and claimed to be typically half the size of a Type 1 file for the same font.
TrueDoc is claimed to be able to deliver the same quality as TrueType and Type 1, with regards to outline fidelity and hinting. Like TrueType and Type 1, scalability means linear scaling only.
The final quality, of ourse, depends on the rasterizer. No experimental results with the Bitstream rasterizer are currently available.
TrueDoc is suitable for left to right as well as right to left languages, as well as mixed directions. Vertical unknown.
TrueDoc is meant to be used on networks. TrueDoc files can be included in documents, or downloaded separately. A single TrueDoc file can contain multiple fonts and/or font styles.
Software is available from Bitstream only. Software is distributed in source form, the encoder (`Character Shape Recorder') has to be bought, the decoder (`Character Shape Player') is probably going to be available for free. Specifications of the format are not available, but might be deducible from the C code.
There is also a version of the decoder (`Font Reconstitution Module') that doesn't rasterize, but instead creates Type 1, TrueType and HP Softfont outlines from the TrueDoc ones, mainly for use with printers. Availability of this software is unknown.
None known.
A size quoted by Bitstream: 16K for Helvetica or Times. What is included in the 16K is not explained, probably a single style only.