The setup of fonts in the TeX world is a complicated and probably frustrating experience for almost all new (and even for many seasoned) TeX users. Several factors contribute to this difficulty:
The TeX Font Server (TFS) project is an attempt to simplify the use of fonts in TeX-related software (DVI drivers in particular); it completely solves the first three problems and it has the potential to reduce or even solve the fourth problem (portability). The fifth problem (design or adaptation of new fonts) is not relevant from a DVI point of view; it has to be dealt by macro/package authors, so it is clearly beyond the scope of this project.
This document presents the project, describes its interfaces in detail and presents a sample implementation demonstrating a working TFS. The project is still in its infancy; all comments, ideas and any feedback are very welcome.
The objective of the TFS project is to enable any user, no matter how inexperienced he may be about TeX, to preview and print correctly any DVI document that uses freely available fonts. The basic idea of the project is to leverage the Web facilities to reduce or eliminate any font installation actions that need to be taken by the user of a DVI driver. In general terms, the installation of fonts requires some specific actions which have already been automated to some extent and for some DVI drivers, but this automation is neither complete (that is, some action is still required by the user), nor universal (the user's actions depend on the DVI driver that he is using).
The logic behind the TFS project is simple: whenever a DVI driver encounters a missing font, it will be able to consult a TFS server and find out the nature of the font (whether it is normal or virtual), as well as download the required files in whatever format is preferred by the DVI driver (or its user). Once those files are downloaded, the DVI driver can proceed normally; there will be no need for any input from the part of the user. The only requirement is that the computer executing the DVI driver has access to the Internet in order to communicate with the TFS server. One can also envision a similar scenario for an intranet; for example, an organization can set up a local TFS server fielding requests from local users; if a request cannot be satisfied by the local TFS server, the DVI driver can consult a ``secondary'' public TFS server; in this way, the users get a fast response from the local TFS, but also have access to more ``exotic'' fonts should the need ever arise.
One could implement the TFS server as a standalone server (eg., like a POP server), but this would be a waste of human resources; the simplest approach is to implement the TFS server as a CGI program running on top of a Web server. The CGI interface supplies the required functionality, is quite easy to program and test, and is available on practically all Web servers,
The intent of this project is to standardize the interface presented by the TFS server to its clients; the implementation of the server is a completely separate issue. We present a free sample implementation written in standard C which uses plain text files for its data; our particular choices were guided by our desire to make this implementation free and as portable as possible. Nothing prevents another implementation written in another language or using another method to organize its data, from being called a ``TFS server'', as long as it follows the interface presented in the following section.
The interface between the TFS server and its clients is quite simple; a client contacts the server and makes a query; the server responds to the query by consulting its database and returning the appropriate information. The entire conversation is performed is defined at the CGI level on top of the HTTP protocol. The TFS server must be able to handle all queries specified in this document; otherwise it cannot be considered a TFS server at all. The TFS queries take the form of a URL to a CGI program:
http://lyra/tfs?op=...&key1=value1&key2=value2...
where:
There is a key parameter common to all TFS queries:
``fmt=...''
This parameter indicates the desired format of the server's response. If this parameter is equal to the string ``html'', then the server's response will be in the HTML format; otherwise, the server's response will be in a plain text format (which is also the default format in case this parameter is missing). Practically all DVI drivers will use the plain text format; the HTML format is only intended to provide an easy Web interface to the server, so that users can explore the server's contents directly from their Web browsers. This is the interface used when you visit the web site of a particular TFS.
Since the HTML response is intended for humans, it is not subject to any strict syntax requirements. The only requirements are that it must comform to the HTML syntax and it should provide at least as much information as the plain text response.
The plain text response is intended to be read directly by DVI drivers and other TFS clients; as such, it must obey a rather strict syntax. Of course, the response varies with each type of query; however, the first line of each plain text response indicates the outcome of the query and it applies to all queries. This line should consist of a number indicating an error code, followed by a colon (:) followed by a description of the error code (this description is meant to be presented to the user for error reporting purposes). All lines in the TFS response should end by the <CR><LF> sequence following the standard HTTP convention.
| Code | Meaning |
| 0 | OK |
| 1 | Internal server error. |
| 2 | Bad or missing operation. |
| 3 | Bad or missing parameters for a given operation. |
| 4 | Unknown font (for the fontinfo query). |
| 5 | Unknown file (for the fileinfo query). |
Let's look now at the available queries and their responses. As mentioned above, each query is specified by a different value of the ``op'' key; furthermore, each query may take a set of different parameters in the ``key=value'' form. This version of the TFS interface specifies the following queries:
The query returns a list of available formats for the requested font. Each format is contained in a single ``section'' which begins the format name enclosed in square brackets ([...]). Valid formats are: VF (Virtual font format), MF (Metafont format), T1 (Adobe Type 1 format), TT (TrueType format). If a font is virtual, then the TFS response should just include a VF section. If the font is non-virtual, then the TFS response will consist of one or more of the MF, T1 or TT sections. In all cases, each section contains the TFM file as well as all files needed to use the font. In the MF section for example, you will see the TFM name, followed by the MF source of the font, followed by any other MF files referenced by the font's MF source. In the T1 section, you'll also see the TFM name, followed by the MAP file, followed by any other files referenced in the MAP file. In the TT section, you'll see the TFM name, followed by the TrueType map file (TTM), followed by any other files referenced by the TTM file. There is obviously some redundancy in the TFS response as the TFM file reference is present in all sections, but this simplifies the task of the TFS client; the general idea is that the client submits a fontinfo query and then selects the most convenient format (or the format selected by the user).
Each line within each section pertains to a font file. The format of the line is:
supplier/typeface/fonfile=URL
The supplier and typeface fields inform the client about the TDS-compliant location of the spefified file. The fontfile field provides the name of the file, and the URL fields specifies an http: or ftp: URL for the file; note that the URL cannot be relative, since it may point to any Internet address. It may appear that the supplier, typeface and filename information is duplicated (since the same information is present in the URL of the example below), but this will not be necessarily true. The specified URL may take any form convenient to the server; the client should not try to extract any information about the font file from the URL field. All the pertinent information lies to the left of the equals sign.
An obvious optimization for a TFS client is to download only the files actually missing from the client machine. At the same time, such a client would be advised to download all missing files listed in the chosen section. One of the services provided by a TFS is the generation of an explicit dependency list; this information can be hard to acquire (especially for MF files), so the clients should use this service; it will actually save them time and effort.
[T1]
public/cm/cmr10.tfm=http://lyra/tfs/tfm/public/cm/cmr10.tfm
bluesky/cm/cmr10.map=http://lyra/tfs/map/bluesky/cm/cmr10.map
bluesky/cm/cmr10.pfb=http://lyra/tfs/t1/bluesky/cm/cmr10.pfb
bluesky/cm/cmr10.afm=http://lyra/tfs/afm/bluesky/cm/cmr10.afm
[TT]
public/cm/cmr10.tfm=http://lyra/tfs/tfm/public/cm/cmr10.tfm
bakoma/cm/cmr10.ttm=http://lyra/tfs/ttm/bakoma/cm/cmr10.ttm
bakoma/cm/cmr10.ttf=http://lyra/tfs/ttf/bakoma/cm/cmr10.ttf
bakoma/cm/bkmcm.tte=http://lyra/tfs/tte/bakoma/cm/bkmcm.tte
To be written...
To be written...
To be written...
Several items will be considered for later versions of the TFS interface; they were left out of the first version of the interface purely for practical reasons.
As described earlier, the installation difficulties of DVI drivers and the portability problems of DVI documents appear to be major impediments to the widespread usage of the DVI format. Technical authors often convert their DVI documents to other formats (eg., PDF) which are more universally accessible. At the same time, these other formats may be suboptimal for some classes of documents (eg., the PS or PDF formats do not yield good results with fonts produced by Metafont). The TFS project has the potential to completely eliminate these problems with the DVI format: any DVI file can be viewed by any TFS-aware DVI driver without the need for any intervention from the user. This feature should be of great help to authors, publishers, administrators and technical support personnel. Moreover, it avoids duplicating the effort required to install TeX fonts on multiple computers. Once a TFS administrator sets up the appropriate entries in the database of the TFS server, then the installation will be automatic to all the TFS clients; this is a tremendous time saver particularly in large TeX installations.
Another not so obvious benefit of the TFS interface is that it provides more freedom to authors of DVI documents. If for example an author wants to use a rarely used font in his document, then he can upload that font to a TFS server (or set up his own TFS server: it's quite simple) and insert a special in the DVI file instructing the DVI driver to use that TFS. The author can then be reasonably certain that his document can be viewed and printed by anybody using a TFS-aware DVI driver.
A sample TFS server is already in operation, although its bandwidth capabilities are rather limited. One can test this server by using the latest version of dviwin (3.2) available from CTAN or the dviwin home page.
The potential of the TFS will be fully realized as more DVI drivers become TFS-aware and as more TFS servers around the globe are installed. We are providing free sample implementations both of a TFS server and a TFS client. They can be downloaded from the TFS project home page. We will also try to help with any questions or problems about setting up such servers and clients.