TeX is a powerful, flexible typesetting system used by thousands of people around the world. It is extremely portable and runs on dozens of widely varying operating systems. One unfortunate consequence of TeX's flexibility is that there is no single ``right'' way to install it. This has resulted in hundreds of slightly (or not so slightly) different installed configurations.
The primary purpose of this document is to describe a standard directory structure for macros, fonts, and other such implementation-independent TeX files. As a matter of practicality, this document also suggests ways to incorporate the rest of the TeX files into a single structure. In the not-so-long run a consistent directory structure will make it much easier to install and maintain TeX. We hope that administrators and developers of both free and commercial implementations of TeX will adopt this standard. It has been designed to work on all modern systems. In particular, the TUG Technical Working Group on a Directory Structure (TWG) believes it is usable under Unix, MS-DOS, OS/2, MacOS, and VMS.
This document is intended both for the TeX system administrator at a site, and for people preparing TeX distributions---everything from a complete runnable system to a single macro or style file. It will also help TeX users find their way around their local system if their local system uses the TeX Directory Structure recommended here.
This version is a draft. Email comments to twg-tds@shsu.edu.
The role of the TDS is to stabilize the organization of TeX-related software packages that are installed and in use, possibly on multiple platforms simultaneously.
At first glance, it may seem that the CTAN Archives fulfill (at least) part of this role, but this is not the case. The role of the CTAN archives is to simplify archiving and retrieval of packages, not their installation and use.
In fact, the roles of the TDS and CTAN are frequently in conflict, as you will discover as you read this document. For purposes of distribution on CTAN, it's useful to combine many different types of files into a single unit; for the purposes of use, it is traditional to segregate files (even similar files) from a single package into separate, occasionally distant, directories.
In this document, ``/'' is used to separate filename components; for example, texmf/fonts/...). This is the Unix convention but the ideas are in no way Unix-specific.
In this document, ``TeX'' generally means ``the TeX system, including METAFONT, DVI drivers, utilities, etc.,'' not just the TeX program itself.
The following typographic conventions are used in this document.
Filenames are typeset in typewriter (constant width) type.
Commands are typeset in italics.
Literal text is typeset in typewriter type.
Replaceable text is typeset in typewriter oblique. Replaceable text, such as package, identifies a class of things.
Many TeX installations currently store large numbers of related files in single directories. Frequently, for example, all TFM files go in a single directory and most, if not all, TeX input files (LaTeX style files, Plain TeX macro files, etc.) go in another single directory.
This monolithic arrangement makes maintenance of a TeX system a nightmare. It can also be the source of catastrophic error if two or more macro packages happen to have input files with the same name.
Therefore, the TWG felt each package and typeface should be in a separate directory. But then explicitly listing all directories to be searched would be unbearable. There are dozens of packages and typefaces a site may wish to install. Aside from anything else, listing that many directories would lead to paths many thousands of characters long, overflowing the available space on some systems.
Also, installing or removing a new package would mean changing a path as well as installing or removing the actual files. This would be a time-consuming and error-prone operation, even with implementations that provide some ability to specify the directories to search at runtime (in a TEXINPUTS environment variable or a system configuration file, for example). On systems without some form of runtime configuration, it could possibly even require recompiling software, an intolerable burden.
As a result, the TWG concluded that a comprehensive TDS required that implementations of TeX must support some form of implicit subdirectory searching. In other words, it must be possible to specify that TeX, METAFONT, and their companion utilities search in both a specified directory and recursively through all subdirectories of that directory when looking for an input file. We encourage implementors to provide subdirectory searching (at the option of the installer and user) for all paths.
This feature is already supported by many implementations of TeX tools including, but not limited to, emTeX (and its drivers), PubliC TeX, Web2C, Y&YTeX, dvips(k), xdvi(k), and DECUS TeX for VMS.
Even if your TeX implementation does not support subdirectory searching, you may still find it useful to adopt the structure if you do not use many fonts or packages. For instance, if you only use Computer Modern and AMS fonts, it it still possible to set them in the TDS and list the directories individually in configuration files or environment variables.
The TWG recognizes that subdirectory searching places an extra burden on the system and may be the source of performance bottlenecks, particularly on slower machines. Nevertheless, we feel that subdirectory searching is imperative to a well-organized TDS, for the reasons stated above. Implementors are encouraged to provide extensions to the basic principle of subdirectory searching to avoid performance problems. One possible extension is the use of a ``database'' of filenames (this can be as simple as a recursive directory listing) that is consulted before directory searching begins. If a hit is found in the database, subdirectory searching is not required and the performance is thus independent of the number of subdirectories present on the system.
As a consequence of the search strategy outlined above, the presence of two identically-named files in a search path leads to ambiguity. The TDS does not define which one is found. To disambiguate this case, a search path must be specified that lists the respective subtrees in the desired search order.
Having accepted that subdirectory searching was necessary, the TWG turned its attention next to other constraints placed on the TDS. The other constraints arise because it must be possible to implement the TDS on any platform. The TWG found that the most constraining environment was the ISO-9660 CD-ROM format. The specifications of this environment are detailed below.
A special note about filenames: most, but not all, operating systems disregard the distinction between upper and lowercase letters in filenames. In the ISO-9660 format, mixed-case names are not allowed. The TDS does not suggest that only monocase names are allowed, although it is clear that mixed-case filenames may cause problems in some environments. Filenames which are identical except with respect to case, are particularly likely to be troublesome.
One place where mixed-case names are known to occur is in LaTeX font descriptor files. Fortunately, LaTeX does not rely on case alone to distinguish between these files. MS-DOS, OS/2, Windows-NT, and MacOS filesystems are not case-sensitive; consequently a request for OT1cmr.fd can always be satisfied by ot1cmr.fd (or OT1CMR.FD). Unix platforms, which do have case-sensitive filesystems, can use links to overcome any restrictions that are encountered. At installation time, a script may produce a whole TDS tree with long, case-sensitive names that consist only of symbolic links (that most systems now support) to the CD-ROM filesystem. The space overhead produced by this ``link farm'' (at 1KB per link) may be negligible compared to the space required for all the files.
One use of the TDS will be the creation of mountable, generic TeX-related distributions on CD-ROM. The only universally acceptable file system format for CD-ROMs is ISO-9660. ISO-9660 is portable and efficient, but it imposes strict limitations on file and directory names:
texmf/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1 1 2 3 4 5 6 7 8
Here is a typical TDS example, using only sevel levels:
texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk 1 2 3 4 5 6 7
Note: Many Unix systems display a modified format of ISO-9660 names, mapping alphabetic characters to lowercase, removing extensions and trailing periods, etc. Naturally, this does not affect the format of names on the CD-ROM itself.
The root of the TDS should be a directory containing only TeX-related materials. In this document, we shall designate this directory texmf, but the exact name of the directory is up to the installer. On PC networks, for example, this could map to a logical drive specification such as T:.
Similarly, the location of this directory within the filesystem is site-dependent. On many systems, this may be at the root of the filesystem; on Unix systems, it would traditionally be located in /usr/local or /usr/local/lib.
The name texmf was chosen for several reasons: it reflects the fact that the directory contains files to an entire TeX system, (including METAFONT, METAPOST, BibTeX, etc., and not just TeX itself) and it is descriptive of a generic installation rather than a particular implementation (such as emtex, or pctex).
The texmf root is not intended to be placed under an implementation-dependent directory. For example, emtex/texmf is wrong.
The top level directories in the texmf directory identify the major components of a TeX system. Not all of these directories are needed at all sites.
The directories specified in this document are:
for input files used by TeX (see Section 3, Macros).
for (non-font) input files used by METAFONT (see Section 5, Non-font METAFONT files).
for METAPOST files (see Section 6, METAPOST).
for font-related files (see Section 4, Fonts).
for files used by BibTeX (see Section 7, BibTeX).
for user documentation (see Section 8, Documentation).
for TeX applications. (In fact, the tex, metafont, metapost, and bibtex directories above may be seen as examples of this.) It may be convenient to store implementations (emTeX, PCTeX, etc.) as well as utilities (dvips, MakeIndex, etc.) in their own directories. Implementations can store configuration files, compiled TeX format files, pool files, METAFONT bases, METAPOST mems, DLLs, etc. in their own directory. Utilities can store configuration files, input files, etc. in their own directory.
for binaries. The system directories allow multiple implementations to share the common directory structure. For example, the binaries for a TeX system on a Sun workstation might be installed in /texmf/bin/spsun413\**
The name spsun413 is one possible abbreviation for sparc-sunos-4.1.3 that could be made ISO-9660 compliant.. Some TeX administrators may wish to put executables outside of texmf altogether.
for sources. This includes both traditional program sources (for example, Web2C sources could go in texmf/source/web2c) and LaTeX dtx sources (texmf/source/latex). The dtx files used for LaTeX distribution contain both the program sources and the documentation sources, so they are kept in the source tree.
Although the TDS is designed to be implementation-independent, the TWG recognizes that some installers may wish to place other files in the TDS. For example, Unix sites may wish to place all TeX-related files (including binaries, manual pages, pool files, and formats) in the texmf tree. This greatly simplifies administration, especially if the TeX tree is maintained by someone other than the system administrator. Moreover, it allows the administrator to construct a single ``TeX server'' (even in a heterogenous network environment).
Note that the texmf tree provides no explicit location for ``local'' files. Consequently, to avoid possible name collisions, sites are encouraged to maintain a separate tree for local styles and to use both trees in search paths. For example:
.:/usr/local/lib/oratexmf/tex//:/texmf/tex//
The common current practice of lumping files into a small number of directories has the disadvantage of making it difficult to determine which input files are associated with which macro packages, and may result in version mismatches and other errors when a package is upgraded, especially if the names of some files change.
To help solve this maintenance problem, the TDS specifies that macros should be stored in separate directories, one for each package:
texmf/tex/format/package/file
is the name of the TeX format that uses these files. plain, amstex, texinfo, latex, and musictex are examples of format. By providing a format directory, subdirectory searching can be limited to only those directories that contain relevant files.
Although some of these formats can also be used as macro packages; the TDS nevertheless stores them as formats. By adjusting the TEXINPUTS search path, it is still straightforward to use them as macro packages under another format, whereas placing them in the tree of another format would completely obscure their possible use as a format.
The following format names are reserved:
Thus, for almost every format, it is correct to search the format directory, and then the generic directory (in that order).
It may be necessary to search other directories as well. For example, the amstex, plain, and generic directories should be searched when using AMS-TeX. This does not mean only those directories must be searched: texmf/tex// is a correct path for TeX inputs in a TDS tree.
The plain directory is intended for files which are useful with the Plain TeX format and others compatible with Plain: fontchart.tex, testfont.tex, manmac.tex, webmac.tex, etc., as well as plain.tex itself and the canonical example story.tex, from The TeXbook. The generic directory, by contrast, contains files which can also be used with LaTeX or AMS-TeX as well as Plain: path.sty, texnames.sty, null.tex, etc.
is the name of a package. amslatex and babel, are examples of packages.
The following package names are reserved:
packages as described in this document are not LaTeX2e packages, even though there exist LaTeX packages with the names listed above. LaTeX packages are style files that add more macro code to document classes. TDS packages are a sets of files distributed, installed, and maintained as units.
In the case where a format consists of only a single file and has no auxiliary packages, that file can simply be placed in the format directory. For example, Texinfo goes in texmf/tex/texinfo/texinfo.tex, not texmf/tex/texinfo/base/texinfo.tex.
Like macros, fonts need to be stored in a hierarchical structure in order to make maintenance feasible. The TDS specifies that fonts should be stored in separate directories:
texmf/fonts/type/supplier/typeface/files
is the type of file stored:
font sources (METAFONT files, property lists, etc.)
TFM files
virtual fonts
Adobe font metrics
PK files
GF files
Type 1 fonts in PFA or PFB format or both.
is the name of the font supplier or public. public, adobe, monotype, and ams, are examples of supplier.
The public directory serves a practical purpose: it designates fonts for which there are no licensing problems if/when they are redistributed.
The name ams is very precisely defined: the ams typeface directory contains only the fonts distributed by the AMS.
is the name of the typeface family. cm, latex, euler, concrete, bookman, and courier are examples of typeface.
The names cm and latex are very precisely defined, as follows. The cm typeface directory contains precisely the 75 fonts defined in Computers and Typesetting, Volume E. The latex typeface directory contains only the fonts distributed with LaTeX in the base distribution.
are the individual files, e.g., cmr10.tfm, putr.pfa, etc. But PK files need additional structure; see the next section.
For more information about font filenames, consult Filenames for TeX fonts.
The PK bitmaps for each font require special attention. In addition to the name of the font, two more characteristics are required to uniquely identify a bitmap font: the type of device (i.e., mode) for which the font was created and the resolution of the bitmap.
fonts with different device types (modes) are generally segregated into separate directories.
Two naming strategies are commonly used to identify the resolution of bitmap font files. On systems which allow long filenames, the convention is to include the resolution in the filename (in fact, this is how METAFONT itself names its output). For example, the 300dpi bitmap of cmr10 is named cmr10.300pk. On other systems, such as MS-DOS, the fonts are generally segregated into different directories for each resolution. For example, the same 300dpi bitmap would be named cmr10.pk in the directory dpi300.
Because the TDS cannot assume long filenames (see Section 2.2) the TDS must use the latter (directory-based) scheme for naming fonts. Therefore, under the pk directory, the TDS specifies two more subdirectory levels:
texmf/fonts/pk/supplier/typeface/mode/dpi/files
is the mode name which identifies the device type. This is usually the name of the METAFONT mode used to build the PK file. ljfour, cx, and linotype are examples of mode. A complete set of METAFONT modes is available from CTAN:fonts/modes/modes.mf.
For PostScript fonts rendered as bitmaps with the ps2pk program, the mode ps2pk should be used. gsftopk is handled analogously.
specifies the resolution of the font. The directory name should consist of the string dpi followed by the numeric value of the resolution in decimal. dpi300, dpi329, and dpi1404 are examples of dpi.
If GF files are also to be kept, they would fall in:
.../gf/supplier/typeface/mode/dpi/files
The TWG recognizes that the use of short filenames has many disadvantages. The most vexing is that it creates dozens of different files with exactly the same name. At a typical site, cmr10.pk will be the filename for Computer Modern Roman 10pt at 5--10 magnifications for 2--3 modes.
There was considerable discussion about how the disadvantages of this scheme could be minimized. One result of that discussion was the decision to allow extensions to the basic naming scheme (such as cmr10.300pk), provided that the basic scheme is also supported. The following statement is the other:
In a TDS-conformant installation, all PK files must contain enough information to identify precisely how it was created; this includes mode, base resolution, and magnification used to create the font.
This information is easy to supply: a simple addition to the local modes used for building the fonts with METAFONT will automatically provide the required information. If you have been using a local modes file derived from (or that is, in fact) the complete modes.mf distribution from CTAN, the required information is already in your PK files. If not, a simple addition based on the code in modes.mf must be made to your local modes file and all PK files must be rebuilt.
Most METAFONT input files are fonts, however a few non-font input files do exist (plain.mf, null.mf, expr.mf, and modes.mf, for example).
The TDS specifies that these files shall be stored in:
texmf/metafont/package/files
package is the name of a group of related non-font METAFONT files (for example, the mfpic macros).
The following package names are reserved:
files are the names of individual METAFONT files like plain.mf or null.mf.
METAPOST is a picture-drawing language developed by John Hobby that is very much like Knuth's METAFONT except that it outputs PostScript instead of bitmaps.
The TDS specifies that the METAPOST input files and the support files for METAPOST-related utilities shall be stored in:
texmf/metapost/package/files
package is the name of a group of related METAPOST files. At the moment there aren't any besides the standard distribution, but the TWG thought it wise to leave room for contributed packages that might be written in the future.
The following package names are reserved:
files are the names of individual METAPOST files like plain.mp.
[ NORM: THE BibTeX LOGO IS BOMBING TEX IN A SECTION TITLE! ]
BibTeX databases and style files are commonly scattered in with other formats, making them hard to find and sometimes making BibTeX hard to understand. In order to reduce the confusion, the TDS specifies directories for them:
BibTeX databases of common interest should be stored in texmf/bibtex/bib. BibTeX style files should be stored in texmf/bibtex/bst.
Most packages come with some form of documentation. To make it easier for users to find this documentation, the TDS specifies that documentation should be stored in a structure that parallels to some extent the fonts and macros directories.
There was much discussion about where documentation files should reside. One option was to place them in the same directory as the source files for the packages, but we felt it was important that users be able to find documentation in one place, not mixed in with the source files; most users have no interest in sources. For these reasons, we decided that a separate but parallel structure for documentation would (1) keep the documentation together and (2) make it straightforward for users to find the particular documentation they were after.
The TDS specifies:
texmf/doc/category/...
identifies the general topic of documentation that resides below it.
In the case of TeX formats, this will be the name of the format: latex, plain, amstex, etc. Within the category tree, the directory base is reserved for ``base'' documentation distributed by the format's authors.
Other categories include utility names, e.g., texmf/doc/bibtex, texmf/doc/makeindx, etc.
The following categories are reserved:
for meta-information, such as FAQ's, David Jones' macro index, etc.
for stand-alone documents not part of any package: Michael Doob's A Gentle Introduction to TeX, Joachim Schrod's Components of TeX, texbook.tex and mfbook.tex, etc.
for manual pages (Unix-style documentation).
for processed Texinfo documents.
for processed HTML documents.
The documentation directories may contain TeX sources, DVI files, PostScript files, text files, or whatever form of documentation will best explain the package.
As noted earlier, the goals of an archive and the goals of working TeX system are sometimes in conflict. We encourage package authors to consider how their packages fit into a working TDS system and to document (or, preferably, automate) how the files should be moved from the archive structure into the TDS structure.
For example, a package for Martian language typesetting might be distributed as the following:
martian-1.0/read.me martian-1.0/doc/martdoc.tex martian-1.0/doc/example.tex martian-1.0/hyphen/marthyph.tex martian-1.0/plain/martian.tex martian-1.0/latex/martian.sty martian-1.0/latex/OT1mart.fd martian-1.0/fonts/martian.mf martian-1.0/fonts/mart10.mf martian-1.0/fonts/tfm/mart10.tfm
Documentation accompanying the distribution should describe how to construct the corresponding TDS structure:
texmf/doc/latex/martian/read.me texmf/doc/latex/martian/martdoc.tex texmf/doc/latex/martian/example.tex texmf/doc/plain/martian/read.me texmf/tex/hyphen/martian/marthyph.tex texmf/tex/plain/martian/martian.tex texmf/tex/latex/martian/martian.sty texmf/tex/latex/martian/OT1mart.fd texmf/fonts/source/public/martian/martian.mf texmf/fonts/source/public/martian/mart10.mf texmf/fonts/tfm/public/martian/mart10.tfm
Note that the main documentation is stored in the latex section of the documentation tree, but the read.me file also occurs in the plain section---presumably to point users to the latex files.
Something like the following:
<texmf>/ top-level directory for TDS tree . bibtex/ BibTeX input files . . bib/ databases of common interest . . bst/ style files . bin/*/ binaries, by system type (optionally) . doc/ user documentation . . <format>/ name of a format (e.g., plain, eplain, amstex, latex) . . . base/ documentation of base distribution for format . . . misc/ documentation of single-file packages . . . <package>/ documentation of packages (e.g., graphics, amslatex) . . html/ hypertext docs (produced by, e.g., texi2html or latex2html) . . info/ processed Texinfo documents (processed by, e.g., makeinfo) . . man/ Unix-style manual pages . . general/ standalone documents . . help/ meta-information (FAQs, etc.) . . <program>/ TeX applications, by name (e.g., makeindx) . fonts/ font-related files . . <type>/ file type (e.g., pk, vf, source, type1) . . . <supplier>/ name of a font supplier (e.g., adobe, ams, public) . . . . <typeface>/ name of a typeface (e.g., cm, euler, latex, times) . . . . . <mode>/ type of output device (for pk and gf only) . . . . . . <dpi>/ font resolution (for pk and gf only) . metafont/ METAFONT (non-font) input files . . base/ base distribution . . misc/ single-file packages . . <package>/ name of a package (e.g., mfpic) . metapost/ METAPOST input and support files . . base/ base distribution . . misc/ single-file packages . . <package>/ name of a package (for future use) . . support/ support files for METAPOST-related utiltities . <program>/ TeX applications, by name (e.g., makeindx, dvips) . source/ program source code . tex/ TeX input files . . <format>/ name of a format (e.g., plain, eplain, amstex, latex) . . . base/ base distribution for format . . . config/ configuration files for format . . . misc/ single-file packages . . . <package>/ name of a package (e.g., graphics, amslatex) . . generic/ format-independent packages . . . misc/ single-file format-independent packages . . . <package>/ name of a package (e.g., babel, german) . . hyphen/ hyphenation patterns
We believe that the TDS has the potential to bring a great deal of order to the current anarchic state of many TeX installations. In addition, by providing a common frame of reference, it will ease the burden of documenting administrative tasks. Finally, it is a necessary part of any reasonable system of true ``drop-in'' distribution packages for TeX.
Adoption of TDS will not be immediate or universal, however. Most TeX administrators will not be inclined to make the switch until:
Consequently, most of the first trials of the TDS will be made by members of the TDS committee and/or developers of TeX-related software. Indeed, some of this has taken place during the course of our deliberations. These trials may result in minor modifications to the TDS specification. They will certainly result in the production of a substantial number of TDS-compliant packages.
Once installable forms of key TDS-compliant packages are ready, some adventurous TeX administrators will set up TDS-compliant trees, possibly in parallel to existing production directories. This ``Beta Testing'' will flush out problems that were not obvious in the confined settings of the developers' sites. In particular, it should help to flush out OS and package dependencies, package interdependencies, and other esoteric details that were not considered by the committee.
Finally, after most of the dust has settled, conservative TeX administrators will begin to adopt the TDS. Eventually, most TeX sites will have adopted the new structure, and most common packages will be readily available in TDS-compliant form.
We believe that the process described above will occur fairly quickly. The TDS committee spans a wide range of interests in the TeX community. Consequently, we believe that most of the key issues involved in defining a workable TDS definition have been covered, often in detail.
Further, a number of TeX developers have been consulted about implementation issues, and have been trying out suggested TDS formats. Thus, we don't expect any big surprises as implementation gets under way.
Finally, there are several (current or prospective) publishers of TeX-based CD-ROMs. These publishers are highly motivated to work out details of TDS implementation, and their products will provide inexpensive and convenient ways for experimentally-minded TeX administrators to try out the TDS.
Efforts are under way to set up a ``TDS Registry'' that will coordinate the assignment of TDS-compliant directory names and provide a definitive database of TDS-compliant software distributions. Interested parties should peruse CTAN:??? or send email to TDSr@cfcl.com.
Defining the TDS required many compromises. Both the overall structure and the names of the individual directories were arrived at by finding common ground among many opinions. The driving forces were achievability (in terms of what could technically be done and what could reasonably be expected from developers) and regularity (like files grouped together in an arrangement that ``made sense'').
The arrangement actually adopted tends to spread files out into two or three places (macros, documentation, and fonts, for example, are spread into different sections of the tree right at the top level).
[ SOMEONE HELP ME HERE, PLEASE, I'M NO GOOD AT WRITING THIS OVERVIEW STUFF ]
The TWG settled on the format/package arrangement after long discussion about how best to arrange the files.
The primary alternative to this arrangement was a scheme which reversed the order of these directories: package/format. This reversed arrangement has a strong appeal: it keeps all of the files related to a particular package in a single place.
In the end, the format/package structure won on a couple of grounds:
The TDS mandates the use of dpi300/cmr10.pk for font naming syntax as it is the only portable form across present-day operating systems. Extensions to this recommendation, such as cmr10.300pk or the use of font library files, may optionally be employed on those systems which support this filename syntax so long as the portable form of the filename is also supported.
The TWG struggled more with the font directory structure than anything else.
The alternative arrangement that we considered was:
texmf/fonts/supplier/typeface/type/
This arrangement greatly improves the maintainability of the font tree, however, unless all the programs which search this tree employ some form of caching, there are serious performance concerns. For example, in order to find cmr10.tfm, TeX would potentially have to search through all the directories that contain all the pk files in all modes and at all resolutions. Clearly, this could make TeX unusable without some method for ``short circuiting'' the search.
In fact, many sites already use this alternative arrangement. It is the arrangement suggested by the Web2C distribution which includes sufficient caching to perform the search efficiently.
In the end, a straw poll of developers revealed considerable resistance to implementing sufficient caching mechanisms, so this other arrangement was abandoned. The arrangement settled on for the TDS allows the search tree to be restricted to the correct type of file, at least. Concerns about efficiency remain, but there seems to be little more we can do.
This appendix is for pointers to files and other documents we mention in this draft.
A User's Manual for MetaPost and Drawing Graphs with MetaPost are available as CSTR 162 and 164 from ftp.netlib.att.com. They are also included as mpman.ps and mpgraph.ps in the METAPOST distribution.
Filenames for TeX fonts can be found in the CTAN archives in the info/fontname directory.
The TWG had no formal meetings (many but not all members attended TUG'94). All discussions were held by email. (Archived on shsu.edu:twg-tds.)
A little bit about each of us, at least who we are and what our affiliations are.
Beeton, Barbara (bnb@math.ams.org). Composition systems specialist and member of the technical support staff, Electronic Products and Services Department, American Mathematical Society, Providence, RI, U.S.A. Editor, TUGboat; charter member and Board member, TeX Users Group.
Berry, Karl (kb@cs.umb.edu). Maintainer of Web2C, Eplain, modes.mf, et. al.
Brown, Vicki (vlb@cfcl.com) editor of ``Prime Time TeXcetera'' from Prime Time Freeware. Vicki has been doing computer-aided document preparation for more than a decade. In her spare time, she works as a Quality Engineer for Taligent.
Carlisle, David (carlisle@cs.man.ac.uk). Research Associate, Computer Science Department, Manchester University, UK. Member of the LaTeX project team.
Jeffrey, Alan (alanje@cogs.susx.ac.uk). Lecturer in Computer Science and Artificial Intelligence at the School of Cognitive and Computing Sciences, University of Sussex, Brighton, UK. Member of the LaTeX project team.
Morin, Rich (rdm@cfcl.com). President of Prime Time Freeware, publishers of ``Prime Time TeXcetera''. Rich has been programming computers for more than twenty-five years, and has written more than 100 columns in magazines such as SunExpert and UNIX Review.
Rahtz, Sebastian (sebastian.rahtz@cl.cam.ac.uk). Production Methods Analyst, Elsevier Science Ltd. (TeX Users Group Technical Councial liaison for the working group)
Schrod, Joachim (schrod@iti.informatik.th-darmstadt.de). Scientific Assistant, Computer Science Department, Technical University of Darmstadt, Germany. Works on formal descriptions of user interface tools and author systems. Active TeXie since 1981; Secretary of DVI Driver Standards Committee (1991--1994), member of several other TUG TWGs (`DVI Driver Issues', `TeX Archive Guidelines', `Multilingual Coordination'), founding member of DANTE e.V.
Walsh, Norman (norm@ora.com). Production tools specialist. O'Reilly and Associates, Inc. 90 Sherman Street, Cambridge, MA 02140. Author of Making TeX Work. (Committee Chair)