KerTeX ``Take care of TeX!'' Thierry Laronde Annecy, FRANCE $Id: README,v 1.33 2012/01/27 12:39:42 tlaronde Exp $ ------------------------------------------------------------------------ 0. Warning, tips and thanks. The authoritative file is the french (``LISEZ.MOI'') one: this is just a translation. (The previous version of Laronde's approximate english has been amended thanks to James K. Lowden... but since there are news, there are probably new barbarisms too!) Despite having been tested, for the latest version, on 3 systems (Plan9/i386, NetBSD/i386, OpenBSD/i386) and compiled also on Mac OSX, Gentoo (Linux) AMD/64 bits PIE and FreeBSD 8.2/i386, it is maturing, but still a beta. In order to allow people to test it safely, the programs and the data are put in dedicated sub-directories, one for the system independent data, and one for the system dependent data and program. Only one program is put in a "common" directory: which_kertex(1). By invoking it, one sees the definitions of the variables for the installation: $ which_kertex readonly KERTEX_VERSION=0.9999.0.2 readonly KERTEX_HOST=netbsd-i386-5.0.2 readonly KERTEX_SHELL=/bin/sh readonly KERTEX_BINDIR=/usr/pkg/bin/kertex readonly KERTEX_LIBDIR=/usr/pkg/share/kertex readonly KERTEX_MANDIR=/usr/pkg/share/kertex/man readonly KERTEX_USER0=root readonly KERTEX_GROUP0=wheel Below, when I write : $KERTEX_BINDIR, this refers to the _definition_ of the variable : it is not by default in the environment, so one has, in this case to replace this symbolic description by the actual value. This way, since we create programs that have the very same name as programs installed by other TeX distributions, our versions will not step on other programs toes. IMPORTANT: TeX expects 8-bit input. This does mean that the character encoding must be an 8-bit one and that feeding TeX with utf-8 won't yield the expect result if the input is not---by design of utf---pure ASCII. One must use, if needed, a filter to convert from utf or whatever to a 8bits range. Furthermore, the fonts used must match. For PIE gcc systems: the binary tools may be wrappers configured to create, by default, PIE executables. In particular, the linkage step---done under cover of the compiler---may not work without problems since we create static binaries. In order to compile on such systems, create a config file like this: cat </tmp/myconf CFLAGS="-ansi -static -O -fno-builtin -Wall -Wstrict-prototypes -Wmissing-prototypes -fPIC" EOT and do make the config this way: .../rkconfig /tmp/myconf MODIFICATIONS ------------- 0.9999.1.1: Bug fixes and, mainly, the support of packages depending on another package. 0.9999.0.4: Bug fixes mainly; adaptations to Plan9 and OpenBSD slightly different utilities syntax. 0.9999.0.2: Addition of e-TeX, the CWEB programs et the first implementation of the packaging system (one added 9 for each of the 3 additions)! 0.9.6.3: - The handling of the reencoded fonts names for PostScript has been corrected; this impacts dvips(1) and MetaPost, and the dvips.cnf file. - Dvips(1) allowed more form of comments in the font map files than MetaPost, while the two programs were supposed to share some: MetaPost now accepts all the comments accepted by dvips(1). - The reserved string "KERTEXSYS" can be added as the last alternative of a search path specification. This adds the default system search paths to the specification. THANKS ------ I'd like to greatly thank the following people for having taken the time to test and report (and for not giving up at the very first error), since this allowed kerTeX to improve (in chronological order): John Floren : test of the LaTeX support, and constant Plan9 support. Alexander Sychev : test of the compilation on Linux (gentoo) PIE. Mark van Atten : test of compilation on FreeBSD 8.2. James K. Lowden : has taken the time and the pain to review the english version (README) and to try to make it look like real english. Todd T. Fries : has taken the time and pain to test on OpenBSD, pin-point the (mainly R.I.S.K.) stumbling blocks (and a buffer overflow blunder in change files). OpenBSD has now its parameter files in R.I.S.K. Doug McKenna: who was trying to get a TeX translated in C for study, managed to do this with kerTeX and found meanwhile a blunder in the size of the char array for the default format name, and a namespace conflict with a non C89 name found in MacOSX libc. ------------------------------------------------------------------------ 1. What. KerTeX is a TeX kernel system, offering the basis on which everything is based: Donald E. Knuth's Digital Typography system. This system includes, of course, METAFONT and TeX; but auxiliaries are also included. All the programs (latest published version) are included here. In addition, other programs linked to Tomas Rokicki's dvi to PostScript driver (dvips(1)) are added, John Hobby's MetaPost, NTS' e-TeX, and Oren Patashnik's bibTeX. To these are added supplementary fonts provided by AMS, and derived the means to work with PostScript core fonts by using AFM published by Adobe. 1.0 : 2D display (x11 and rio) for METAFONT. ------------------------------------------------------------------------ 2. Principles. Donald E. Knuth has written, described, explained the programs using his WEB system for literate programming, allowing the best human oriented exposition, while letting a program assembling the sources the way a compiler expects them to be. The programming language of WEB is Pascal. (There is a C and derived languages version, called CWEB; I [TL] use this one intensively.) The problem is then to manage to compile this Pascal program on the systems. Donald E. Knuth has greatly simplified the subject, not only thanks to literate programming (books with indexes), but also by marking explicitly the system-dependent sections and by using only the most basic (and hence translatable) Pascal constructions. But the normalization of Pascal is a very recent attempt, and Pascal compilers are relatively rare, or have incompatibilities. Because C compilers are ubiquitous, the solution adopted by Tomas Rokicki beginning 27 years ago was to translate Pascal to C. This is de facto what is done here, using the 5.0C version of Web2C (public domain) as a basis. KerTeX splits logically the steps: 1. We first build the tools translating from WEB to Pascal, and then from Pascal to C, on the _matrix_ (the node compiling) => this is kertex_M. 2. We use then the matrix C system plus the tools of kertex_M, still on the matrix, to build the binaries for a defined combination of machine and operating system : the _target_ (there can be cross-compilation) => kertex_T. 3. _When installing_, we use the binaries (the matrix can compile but has no obligation to be able to run) to build the following: a) The ``dump'' of METAFONT so that we can name a program mf(1)---since kerTeX passes the TRAP test. b) We use a) to build the Computer Modern fonts. c) We then use the TFM generated in b) to ``dump'' the plain format of TeX, leading to a version that has the right to be called tex(1)---since kerTeX passes the TRIP test. d) The ``dump'' of MetaPost so that we can name a program mpost(1)---since kerTeX passes the TWIST test (name adopted in kerTeX for MetaPost à la METAFONT torture test). e) The generation of supplementary fonts, whether from AMS provided METAFONT sources, or from PostScript core fonts using AFM published by Adobe. Please note that by including the sources for Donald E. Knuth Computer Modern fonts supplementary to the programs, we obtain a system that conforms to the one described in: Donald E. Knuth, Computers & Typesetting, volumes A-E, Addison-Wesley. Furthermore, kerTeX aims to be a TeX kernel system. KerTeX can be considered as a guest OS running on a host. Hence, installing kerTeX is make kerTeX run on a host (kerTeX has been designed to have maximal portability, for eventually a maximum of OSes, and for almost all the size of OS). The aim is also that installing a TeXpkg is kerTeX business: once the system is installed, kerTeX deals with TeX packages; the burden of creating packages for every OS is relieved. A package is created once and for all for the TeX system. ------------------------------------------------------------------------ 3. For whom. We have cleaned the generation process so that we have C89 compliant sources. This means that kerTeX can be available for virtually every operating system with a C89 compiler and library. The compiled programs depend only on libc. At execution time, only MetaPost depends on scripts written in a basic Bourne shell language. Hence, a Bourne shell has to be installed, or the handful scripts converted to the host interpreted language. Finally, the administration of the system is more demanding. A Bourne shell, still, but also a few essential utilities. But, ,,at the worst'', only a limited subset of POSIX.2 utilities are used and the sys dependent part are clearly identified in the sources hierarchy. [There is a lot to say about all this, and the numerous solutions. Enough for now.] As an example, some programs, needing the use of several files, were opening ``/dev/null'' when one argument was not given. We have replaced this by ``null.mf'' or ``null.tex'', since they are empty (except for comments) files---they are in D. E. Knuth's sources...---. But, if the sources are C89, to be able to build we need tools. The compilation process expects POSIX tools: sh(1), make(1) and a small subset. So, the programs are C89; but the compilation process is POSIX. This is handled by the R.I.S.K. : Reduced Instruction Set toolKit, that has to be hosted on a POSIX compliant node. It should work on a huge number of Unix like system. It works at least on NetBSD, FreeBSD, Darwin (MacOS X) and Plan9 (under APE). Nothing prevents cross-compilation for non POSIX systems (think mingw). In any event, if an adaptation has to be made, it's in R.I.S.K., almost certainly not in the kerTeX sources. ------------------------------------------------------------------------ 4. Compiling, installing and upgrading. For motives linked to the licence, but also to clarify what is under the kerTeX licence and what is not (it was not very clear in the COPYRIGHTS, all the authors and the licences being cited at the beginning), the sources have been split in several chunks. To be short, I [TL] has forked Public Domain code and Public Domain programs that were officially orphaned by their original. To these are added my own organization of the whole, modifications and new code. These elements are the one in kertex_M and kertex_T. For the other elements that have very permissive licences but are, to my knowledge, still maintained by their authors, the sources have been put in dedicated chunks. This allows too more fine grained updating since kerTeX more frequently than the external sources. Note 1: these sources are reorganized for kerTeX and have been gathered from here and there. Note 2: for the NTS team: the etex.ch in the sources is not the one in the sources I have found since I had to adapt them for the new TeX version. I'd like someone to review. Thanks! It shall be noted that, concerning the licence, two things must be thought separately: the moral rights, that are inalienable: whether the code is in the P.D. or not, the author(s) stay(s) the author and his/their name(s) shall never be erased; secondly, there are the patrimonial rights (what can be done pratically with the code). I have made efforts to respect scrupulously this and to give credit when it was due. All the authors are cited. And if the cleaning of what had become a mess could give the original authors the incentive to have pleasure working back on their code, I will be more than happy ! What has to be done has been written done in: get_mk_install.sh (for Unices) get_mk_install.rc (for Plan9) Both scripts are downloadable on the kerTeX dedicated Web page. Whether run the script or read it, or both... http://www.kergis.com/en/kertex.html Upgrading. ------------------------------------ During an upgrade of an existing installation, all the files and programs under the sole responsibility of kerTeX---i.e., not user-configurable---are simply overwritten. But some files are meant to be customized; with these, the R.I.S.K. framework has them declared "precious" and will ask the user what to do with them, offering to visualize the diff, to install the new version or to skip the file. Two files of the latter type: 1) dvips.cnf: dvips configuration file. It shall be noted that until the stable release 1.0 is reached, the organization of the hierarchy of kerTeX may change and this can have an impact on what has to be---for the kerTeX part---in this file. Look at the diff but install the new one for now, customizing it afterwards. 2) psfonts.map: the PostScript fonts handled by TeX, dvips(1) and MetaPost. The kerTeX provided ones are described in a chunk guarded by comments allowing the upgrade. You can add your fonts in this file, outside the kerTeX administrated chunk. The other customizations are the formats (base, fmt and mem) generated when precompiling big METAFONT, TeX or MetaPost package (ex.: latex). But latex(1) is just a copy of virtex(1), named this way in order to instruct the program to load the precompiled format "latex.fmt". Since we _copy_ an executable that is statically compiled, "your" version will still work. But if the TeX program has been modified, or (more probably) the searching kerTeX library linked with, this version will not have these modifications. Simply copying the new virtex(1) and renaming it latex(1) may work, but not in all cases since if TeX has been modified, some magic numbers used to verify that a format is compatible will have changed (you will have a "Fatal format file error; I'm stymied"). The safest is to recompile and recopy. ------------------------------------ ------------------------------------------------------------------------ 5. Dealing with packages. New! The first implementation of a packaging handling has been developed. Ainsi kerTeX uses for itself this framework to compile the dumps and the fonts. After installation, you can verify the paths by: $ which_kertex readonly KERTEX_VERSION=0.9999.0.2 readonly KERTEX_HOST=netbsd-i386-5.0.2 readonly KERTEX_SHELL=/bin/sh readonly KERTEX_BINDIR=/usr/pkg/bin/kertex readonly KERTEX_LIBDIR=/usr/pkg/share/kertex readonly KERTEX_USER0=root readonly KERTEX_GROUP0=wheel et you have to run: $ $KERTEX_BINDIR/adm/pkg_core install that will compile the data. This is done so because METAFONT, TeX and al. are very powerful engines, and running them as root (where this notions makes sense...) is a security risk: the programs deal with files and are able to do a lot of things that are orthogonal to their first aim. The packaging framework compiles everything under an unprivileged user (for now: refuses to run as id 0), and switches to root only when installing the files. As an example, the script (see the website): pkg_latex.sh is provided, and by running it this way: $ $KERTEX_SHELL pkg_latex.sh install it retrieves, compile and install the latest version. [Note that the size of the result (with the doc) is not very far from the size of the kerTeX system alone...] ------------------------------------------------------------------------ 5. ``Mettre en oeuvre'': running/using the programs The french expression conveys the meanings: the explanations that follow, ``allow you to put the programs in a state that allow you to make something with them : a work of art'' : this is the meaning of the 3 french words... There is only one rule to learn: the way the programs search for their inputs. If one obeys the kerTeX hierarchy, the default path-searching algorithm should work with added packages (say, latex). The default path search specifications are defined at compilation time with the 2 following alternatives: 1) The current directory ('.'). 2) The dedicated kerTeX directory: for example /lib/kertex for macros (KERTEXINPUTS) on Plan9; this is prefixed /usr/pkg on NetBSD etc. If the environment variables are not defined, kerTeX searches for files exploring the default paths. If the environment variables are defined, their content overwrites the default paths. But as a convenience, the i reserved string "KERTEXSYS" as the last component of any path specification instructs kerTeX to append the default search paths to the specified ones. Example: KERTEXINPUTS="my_dirs:KERTEXSYS" will launch searches first in my_dirs, and, if the file is not found, in the default directories searched for this path specification. The search is done for each of the alternatives in turn and ends as soon as the file is found. If the file is not found directly in the directory, a subdirectory with the basename of the program is searched (for example with dvips(1), the second try will search in a dvips/ subdirectory; this works with every program). These variables can be redefined by the user in the environment: $ KERTEXINPUTS="bla-bla-bla..."; export KERTEXINPUTS KERTEXINPUTS is a ':' (colon) separated list of directory to search, as are the other ones listed below. Shared by several programs: KERTEXFONTS: as important as KERTEXINPUTS, but for fonts and for both TeX and dvips. TeX, for example, works with TFM (TeX Font Metrics) that give him the metrics to assemble the basic elements, the glyphs. If loading a font fails, TeX has not found the corresponding *.tfm in its paths. The search routine, shared by all the KerTeX programs, take in turn every directory specified in the colon separated list, searching perhaps first for a subdir (tfm/, pk/, cm/, gf/, pfa/, pfb) and if this fails without the subdir, until the file is found or the path specification is exhausted. For METAFONT, TeX and MetaPost: KERTEXPOOL: the messages to the user. The program _must_ find them to run. Why are they put outside? Because this allows you to translate, or customize. Uh!!! Eh, yes!... KERTEXINPUTS: the path to search for macros, generally *.mf. If an "\input" fails, you know now why. KERTEXDUMP: if the format has been dumped, according to argv[0], METAFONT/TeX tries to load a argv[0].{base|fmt}. This is where it searches for. For dvips and BibTeX: KERTEXINPUTS: the path to search for configuration files (*.cnf), chunks of PostScript programs to include (*.ips), fonts maps (*.map), encodings (*.enc) and files your document includes (probably eps images), or style files, bibliography databases for bibtex(1). For the CWEB programs (ctangle(1) and cweave(1)): CWEBINPUTS: one can define alternative paths ':' separated. Other more specialized programs (linked with WEB etc.) need to be initialized for looking in directories they don't "own". The initialization is done in the source, and they don't take into account the environment variables. Since they always search in the current directory first, this should not be a problem. ------------------------------------------------------------------------ 6. John Hobby's MetaPost. MetaPost has been added to kerTeX. Some differences with current distributions are worth noting: - For consistency, MetaPost does not handle the `-I' flag anymore. Like mf(1) and tex(1), there are now inimp(1) and virmp(1). Instead of using the removed flag, use inimp(1). - Still for consistency---even if the util is not directly seen by the user---the script makempx has been renamed texmpx(1) for symmetry with troffmpx(1). - The generated files are produced in the current working directory, including .mpx in ordre to allow the use of MetaPost with read-only sources. - The only non-C89 (but POSIX.1) util was newer(1) and has been replaced with customized Bourne Shell commands in the scripts, so that all the compiled programs are only C89; the adaptation, if needed, was trivially limited to the scripts. - Finally, since the MetaPost torture test is its own, it has now a dedicated name in kerTeX: TWIST! (see below) MetaPost can use troff(1) to generate labels. But troff has to find fonts and the map has to be customized. See the manpage mpost(1). ------------------------------------------------------------------------ 7. Testing. Donald E. Knuth has given torture tests in order to verify implementations claiming to be METAFONT and TeX. John Hobby has done so too for MetaPost, as well as the NTS team for e-TeX. To run the tests, do: $ $KERTEX_BINDIR/adm/ck_tex $ $KERTEX_BINDIR/adm/ck_mf $ $KERTEX_BINDIR/adm/ck_mpost $ $KERTEX_BINDIR/adm/ck_etex The result is published on stdout, with informations on how to read the results and where to found the corresponding manuals. Our implementations pass the tests. ------------------------------------------------------------------------ 8. From dvi to Adobe PostScript(R). The layout compiled by TeX is in the dvi format. To have a representation of it, whether on a screen or on paper, one has to read the dvi and to convert it to instructions understood by the device giving the representation. dvips(1) is the driver translating dvi into PostScript. The configuration file is: [/usr/pkg]/lib/kertex/dvips/dvips.cnf (it is called "config.ps" in other dvips(1) distributions). To be able to know the amount of available memory and the language level supported by a PostScript printer, one can send the following PostScript program to the printer: ----------BEGIN PS---------- %!PS /Times-Roman % we will use this font 14 selectfont % current font at 14pt 72 432 moveto % we don't know the size of the paper; just enough vmstatus % returns level used maximum exch sub % exchange used and maximum and subtract used from max 20 string cvs % allocate string and convert value to it (free memory: ) show show % the string stacked pop % pop level 72 412 moveto (language level: ) show languagelevel 20 string cvs show % idem showpage % fiat lux %%EOF ----------END PS---------- KerTeX dvips(1) is a modified version. Please note: - This a pure C89 version; all system-dependent code has been removed. Specially, dvips(1) doesn't try anymore to send PostScript directly to the spooler : it produces a PostScript program. Period. It sends it, by default, to stdout. that lets your decide to redirect to a file: $ kertex/dvips file.dvi >file.ps or: $ kertex/dvips -o file.ps file.dvi or transfer to the spooler: $ kertex/dvips file.dvi | lpr Only the directory separator and the system encoding are handled. But this is done by the R.I.S.K. infrastructure, and not the dvips code by itself (adaptations should be made if necessary to the R.I.S.K parameter files and the code should be left alone). The main goal was to still support EBCDIC. - The support for "backtick commands" has been removed: the commands embedded in a dvi file and supposed to be executed directly via system or popen are not handled. (This is an important security risk and furthermore the result can be achieved by the user via preprocessing.) - The automatic generation of missing fonts (METAFONT) is still here, but it is not on by default: you have to specify the (new) option "-G" to get it. If the automatic generation was not set or if it fails for a missing font, the command line to use is sent as a comment on stderr for the user to have hints about what and how to do. Note that the missfont.log that was previously written to hold this information is no longer created. By design, dvips(1) creates streams (on stdout and stderr) and does not write anything by default. Hence it can be used "flying over" a read-only directory. - emTeX and TPIC \special's handling is removed. - Support for HyperTeX (for PDF hyperlinks) is included. - Support for Adobe T1 works. By default (in the dvips.cnf file), the T1 version of the Computer Modern are used. The use of the fonts is set by map files that specify the name used by TeX, the name to use in PostScript, perhaps a different encoding, and perhaps a file to embed in the PostScript code. All is a question of configuration (map files), and the simpler is to read Tomas Rokicki's manual, included in source form in the KerTeX distribution. For the options the MAN page is up-to-date. For the tutorial, especially for the font handling, consult Tomas Rokicki's manual (not modified, so not completely accurate for the options that have changed, but still the reference for the fonts) : cp [/usr/pkg]/lib/kertex/dvips/dvips*.tex /tmp cd /tmp # You should have dvips.tex and dvipsmac.tex here. kertex/tex dvips.tex # dvi production kertex/dvips -G dvips.dvi >dvips.ps # some fonts (logo) to generate To test the dvips installation, Tomas Rokicki's test page is great: #BEGIN_DVIPSCK TARGETBINDIR=/usr/pkg/bin # bin host repertory (NetBSD) KERTEXLIB=/usr/pkg/lib/kertex # machine independent kerTeX stuff cp $KERTEXLIB/dvips/doc/test.tex /tmp cd /tmp # Warning! two passes. The first produces an error message that is # normal since we generate precisely the file the program doesn't find. # Don't try to be smart by naming directly the first ps "mtest.ps" or # you will enter not an infinite loop, but a loop terminated when # your disk is full... # $TARGETBINDIR/kertex/tex test.tex $TARGETBINDIR/kertex/dvips test.dvi >test.ps # a non fatal and normal error mv test.ps mtest.ps # mtest.ps is the name of the included file. $TARGETBINDIR/kertex/dvips test.dvi >test.ps # Look! #END_DVIPSCK ------------------------------------------------------------------------ 9. Fonts. This is a whole subject by itself, one that won't be covered in the following, but only skimmed for the peculiarities of the kerTeX distribution. The user must keep in mind that some subdirectories are now---for kerTeX--- a plain part of a font name. Instead of putting everything flat at the same level fonts with different encodings and so on, the encoding is specified as a subdirectory, à la Unix filesystem hierarchy. (This is crucial, since dvips(1) has been modified to handle differently what used to be called ``areas''.) TeX is a formatter, so to say, that doesn't ``see'' the strokes of the characters it gathered; but has to know the metrics in order to do its job. Hence, it is possible to use with TeX fonts that are only described by their metrics, but whose glyph definitions are not published---but expecting that when a rendering is requested, a device will be able to fill this ``gap''. Furthermore (and finally) for TeX a character is an integer: the encoding is fundamental; and the encoding of the font must match the encoding of the stream of characters fed to TeX. But opportunities exist at different levels to make transcriptions. In particular, Adobe published the metrics for the PostScript Core Fonts that are to be found in every compliant PostScript device. So these fonts can be used with TeX. The main advantage---that could be obtained with Donald E. Knuth's Computer Modern by creating virtual fonts---is the ability to use a full latin1 range, i.e. the accented letters directly, without resorting to ligatures. But, by default, PostScript standard encoding is not latin1. Hence the obligation to make several manipulations behind the scenes. Fonts usable with a latin1 encoding are created at installation time and put in a dedicated subdirectory: PKGDIR/fonts/tfm/tex-latin1/ They must be used specifying the subdirectory as part of the name: \font\tenrm=tex-latin1/Times-Roman at 10pt for example. The subdirectory here specifies the encoding (it is not interpreted as an encoding: it is a means of organization), this encoding being compatible both with plain TeX conventions and latin1, the font having its PostScript name with a suffix if it is a modified version, suffix introduced by `_' and followed by: - `c' it it is a condensed (narrower) version; - `e' if it is an extended (stretched) version; - `o' if it is an oblique version (from an non oblique one); - `u' if it is a straight (upright) version from an oblique one; - "sc" for a small caps version. Here is a list of the tfm created at installation time: tex-latin1/Courier-Bold.tfm tex-latin1/Courier-BoldOblique.tfm tex-latin1/Courier-Oblique.tfm tex-latin1/Courier.tfm tex-latin1/Helvetica-Bold.tfm tex-latin1/Helvetica-BoldOblique.tfm tex-latin1/Helvetica-BoldOblique_c.tfm tex-latin1/Helvetica-Bold_c.tfm tex-latin1/Helvetica-Oblique.tfm tex-latin1/Helvetica-Oblique_c.tfm tex-latin1/Helvetica.tfm tex-latin1/Helvetica_c.tfm tex-latin1/ITCAvantGarde-Book-sc.tfm tex-latin1/ITCAvantGarde-Book.tfm tex-latin1/ITCAvantGarde-BookOblique.tfm tex-latin1/ITCAvantGarde-Book_sc.tfm tex-latin1/ITCAvantGarde-Demi.tfm tex-latin1/ITCAvantGarde-DemiOblique.tfm tex-latin1/ITCBookman-Demi.tfm tex-latin1/ITCBookman-DemiItalic.tfm tex-latin1/ITCBookman-Light-sc.tfm tex-latin1/ITCBookman-Light.tfm tex-latin1/ITCBookman-LightItalic.tfm tex-latin1/ITCBookman-Light_sc.tfm tex-latin1/ITCZapfChancery-MediumItalic.tfm tex-latin1/NewCenturySchlbk-Bold.tfm tex-latin1/NewCenturySchlbk-BoldItalic.tfm tex-latin1/NewCenturySchlbk-Italic.tfm tex-latin1/NewCenturySchlbk-Roman-sc.tfm tex-latin1/NewCenturySchlbk-Roman.tfm tex-latin1/NewCenturySchlbk-Roman_sc.tfm tex-latin1/Palatino-Bold.tfm tex-latin1/Palatino-BoldItalic.tfm tex-latin1/Palatino-BoldItalic_u.tfm tex-latin1/Palatino-Italic.tfm tex-latin1/Palatino-Italic_u.tfm tex-latin1/Palatino-Roman-sc.tfm tex-latin1/Palatino-Roman.tfm tex-latin1/Palatino-Roman_c.tfm tex-latin1/Palatino-Roman_e.tfm tex-latin1/Palatino-Roman_o.tfm tex-latin1/Palatino-Roman_sc.tfm tex-latin1/Times-Bold.tfm tex-latin1/Times-BoldItalic.tfm tex-latin1/Times-Bold_o.tfm tex-latin1/Times-Italic.tfm tex-latin1/Times-Roman-sc.tfm tex-latin1/Times-Roman.tfm tex-latin1/Times-Roman_c.tfm tex-latin1/Times-Roman_e.tfm tex-latin1/Times-Roman_o.tfm tex-latin1/Times-Roman_sc.tfm The fonts that were described historically with only 8 letters are provided, but for compatibility only. There is no "missing" font: a package using other fonts must create, generate, and provide them. Distributed by kerTeX are obviously the Computer Modern fonts from Donald E. Knuth, with their PostScript T1 transcriptions provided by AMS, and all the other fonts publicly provided by AMS. The standard PostScript fonts are usable from the metrics provided by Adobe (see above), but only the metrics are here: the definition of the strokes must be provided by the rendering device. (For example, a software rendering dvi would not be able, as is, to draw the correct result if it has no compatible fonts to draw from ; but the dvi will be printable by a PostScript printer, for the very reason that the printer, if PostScript, has the font definitions.)