Setting Up emTEX^{∗†}

(under MS-DOS)

by

Daniel H. Luecking

Preface

There are frequent posts to the newsgroup comp.text.tex about difficulties encountered in obtaining or installing emTEX (the excellent free implementation of TEX for the PC by Eberhard Mattes). Since I had to go through the whole thing for a second time, I decided to try to keep notes and write a report in case it might help others embarking on the same task. I offer the result here. I have tried to include even my mistakes if that seemed like it would help someone avoid the same. This is offered only as an EXAMPLE of what might be done (thereby showing the newcomer that it CAN be done) and NOT as a recommendation of what ought to be done. Users of OS/2 can possibly benefit from my experiences. But I have NO experience with that operating system and so cannot even guess what differences there might be in the process.

Several caveats: (i) This is not intended as a tutorial. I have assumed in this report that the reader is familiar with the general idea of a TEX system: There is an executable program (usually called something like tex.exe on a PC) which loads a format file, reads a .tex file, may read some .tfm files, and produces a .dvi file. There should be executable programs called drivers (for printing or previewing) and these usually require font files (.pk files or emTEX’s font libraries—no Postscript in this version of my report). (ii) PC’s differ, your mileage may vary. You are assumed to understand your setup and know how to use DOS. I accepted emTEX’s default directory structure; it makes things go so much more smoothly. If you absolutely must have a different structure, you have several extra steps to go through. Read the manual(s) to find out what these are (see rules 1 through 4 in §§1 and 2). (iii) There may be occasional omissions (my notes are not terribly complete or comprehensible) and/or typos that render some of the following unreliable. No warantee is expressed or implied. You are on your own. No guarantees. Make sure you back everything up first. Don’t bother me! Nothing is my fault!! (Have I made my position clear?) Nevertheless, clarifications and corrections of factual errors will be sullenly welcomed. Mail them to

    DL24794@uafsysb.uark.edu

Ignore any address in the header or signature if you got this from me via e-mail. (iv) I am not the authority on emTEX nor an expert in DOS. Please send only corrections: I give no guarantee that mail to me for any other purpose will be answered (or even read). In compensation for this, I offer the following: There is an emTEX specific discussion list to which EM himself frequently contributes.

    TO SUBSCRIBE write to: emtex@chemie.fu-berlin.de
                        or: emtex-user-request@chemie.fu-berlin.de

TO POST A MESSAGE that will be received by all subscribers, write to:

                             emtex-user@chemie.fu-berlin.de

DO NOT send subscription requests to the last address and DO NOT post queries to the first addresses. The list emtex-user is for questions and discussion of issues relevant to the emTEX package of programs and files. For discussion of TEX in general the newsgroup comp.text.tex is a more appropriate forum, or one of the TEX-related discussion lists.

∗ emTEX is the excellent TEX system for the PC developed by Eberhard Mattes. It pains me that the nature of this article has forced me to concentrate more on the difficulties than the beauties. For this I apologize to E. Mattes. All good features of emTEX are due to his efforts, all unfortunate features are the fault of MSDOS. :-)

† \begin{matrix}c \\ ◯ \end{matrix} 1993 by Daniel H. Luecking Section 1. Acquiring emTEX

emTEX is available from all good TEX archives (this is part of the definition of ‘good’). The standard one is the Stuttgart archive ftp.uni-stuttgart.de (in DEutschland). The Aston archive ftp.tex.ac.uk (in the UK) is another. Another is pip.shsu.edu at Sam Houston State University in Texas.^{1} The first time I acquired emTEX I found it at the University of Michigan (msdos.archive.umich.edu). I frequently had trouble connecting there; perhaps it was too busy. I understand the Washington University archive (wuarchive.wustl.edu) may mirror the Michigan one.

As my first step, I actually ftp’ed to niord.shsu.edu. This was quite slow and should now be considered as having been replaced by pip.shsu.edu for ftp purposes. What I describe below is what I would have done if pip had been available. (I have tested these commands just to be sure.) If you choose one of the other CTAN sites, the only difference would be that “tex-archive” would be replaced by “pub/archive” or “soft/tex.” ^{2} After issuing the command ftp pip.shsu.edu from my HP-UNIX account I am prompted for a name and I type anonymous and then give my e-mail address for a password. The following commands ensue (cryptic messages and nonessential commands removed):

    ftp> cd tex-archive
    ftp> cd systems/msdos/emtex/disk1
    ftp> mget *.eng
    ftp> quit

This downloads the three files

    readme.eng changes.eng help.eng.

(Native speakers of German would want to get *.ger instead.) After quitting the session, I printed out these files. The first three rules for working with emTEX are

(1) Read these three files.

(2) Read them again.

(3) In case of confusion, consider repeating rule 2!

This is not as hard as it might at first seem; they are short files (except for readme.eng, but most of its length comes from a list of the files contained in the complete package).

The download from niord was extremely s-l-o-w (pip is quite speedy, but was not available then), so I decided to try a faster source for the remaining files. Out of curiosity (and so I’d know what I’m talking about in this report) I tried the standard source:

    ftp.uni-stuttgart.de

in directory

    soft/tex/systems/msdos/emtex

1 The TEX archives on these three hosts mirror one another. They currently constitute CTAN, the Comprehensive TEX Archive Network. They not only contain the same TEX material but also the same directory tree. It grows from the following roots.

    pip.shsu.edu::tex-archive/
    ftp.tex.ac.uk::pub/archive/
    ftp.uni-stuttgart.de::soft/tex/

2 If you don’t know how to download material by ftp, do what I did the first time: ask someone nearby. If you don’t have access to ftp, write to your local or national TEX Users Group for ways to acquire emTEX on disk. The FAQ (the file of frequently asked questions) from comp.text.tex may give the address of your TUG. The FAQ may be found in any of the CTAN hosts in directory help.

(at that time the directory structure was actually slightly different.) This was an evening session and proceeded very quickly.

Under the .../emtex directory are subdirectories /disk1 through /disk6, /betatest, and several /*_fonts. I changed to each /disk* directory in turn and downloaded all the files in each directory. (The Stuttgart archive sends files in binary mode by default. This is not true of many archives. All .zip files MUST be transferred in binary mode.) I did the same with the /betatest directory. That finished my latest download of emTEX. The first time I did this (a couple of years ago from UMich) I also got the contents of the directory .../emtex/lj_fonts, consisting of 8 files lj_*.fli, which are Font LIbraries containing fonts for the HP LaserJet and screen preview—essentially all the standard TEX/L^{A}TEX fonts at 300dpi in \magsteps 0 to 5. (emTEX itself was slightly updated since then, but the Font LIbraries are apparently the same.)

If you wish to distribute emTEX you MUST distribute the whole 6 disk set unchanged. Since I had no need to do this, I began deleting those parts that I did not need. This included all the German language specific packages (all g*.zip plus lkurz.zip plus *.ger). Also, since I intended to install the beta test versions (which include a big TEX, tex386), I deleted the big TEX files (btex.zip, blatex.zip, etc.). This was maybe a mistake but it has not yet caused any significant difficulty. There are a few other packages that I did not install but did not delete such as web.zip. On my first go-around I did not install (the mf*.zip and bmf*.zip files). What to delete will be made clearer by following rules (1)–(3).

Section 2. Installing on the PC

I now had emTEX in my HP-UNIX account and needed to get it to my PC, which is not networked, so I needed to download it to a PC work station, transfer it to disks and carry it to my PC. It consists of 6 disks of emTEX (only partially full because of the deletions I mentioned above) plus the (previously acquired) 5 disks of lj_*.fli, plus about 2 disks of the beta test files. I copied the lj_*.fli to the directory C:\texfonts (this choice made installation easier as you will see). Then, with C:\ as my current directory, I did the following with each of the 6 disks of emTEX in drive A: (but not yet for the beta test disks)

    pkunzip -do a:\*.zip

This assumed that the program pkunzip.exe was in a directory in my path. (It was. If you do not have pkunzip.exe, it is supplied with emTEX and you need only copy it to the root directory.) The ‘-d’ option of pkunzip recreates the default directory structure of emTEX stored in the .zip files. This brings us to the fourth rule for working with emTEX:

(4) Accept the default directory structure.

You will be glad you did. If you had a previous version of emTEX installed with the default directory structure, the ‘-o’ option overwrites most (all?) of the files of the previous version. If you had modified any of those files to suit your setup, you would have to do it again. A better idea is expressed in the fifth rule:

(5) Modify only renamed copies of the files distributed with emTEX.

This makes updates easier. (Nevertheless, I admit to violating this rule more than once.) I then copied remove.exe and delete.exe (from disk1, I think) into c:\emtex (a directory created by the pkunzip command). I don’t know if they will ever be needed, but as they came with the package, I decided to keep them. They are used to uninstall portions of emTEX. Finally, I copied *.eng into c:\emtex\doc\english

and deleted c:\emtex\doc\german\*.*

What I now had was emTEX installed in default directories and needed to set only a few environmental variables. One of these was the PATH variable, to include the directory C:\emtex—where all the executables are stored—in my search path. I did this, but in my haste I forgot to set some of the others (in particular, DVIDRVFONTS, to tell the drivers where to find the fonts). Instead, I immediately cd’ed to c:\emtex\doc\english to view the manual, emtex.dvi. I issued the command

    v emtex

which calls the batch file v.bat and I was immediately informed that fonts could not be found. Realizing my error I tried the following:

    set-tex

which calls a batch file that sets to their more-or-less default values all the variables emTEX needs. There is no default for the font directory, which is why the screen viewer couldn’t find the fonts, but the batch file set-tex.bat sets the variable DVIDRVFONTS to C:\texfonts, which is where I had put them. (You need a lot of environment space for all these variables, but I already had mine at 1024 bytes.) Now

    v emtex

produced the expected title page of the emTEX manual on the screen. Success!

Calling ‘set-tex.bat’ as above might not work for you. It sets a fair amount of rather long environmental variables and you may get the DOS message ‘Out of environment’. In that case, you have several choices:

(i) with the default directory structure, edit set-tex.bat to set only the variables beginning ‘DVIDRV...’ such as DVIDRVFONTS. Then add the line

    set emtexdrv=C

This causes emTEX to assume the default directories reside on drive C:. You would use whatever the letter of your drive is. Most of the programs (except the drivers) will search default directories if no variable or switch is use. Or (ii) increase your environment space with a line like

    SHELL=C:\DOS\command.com /P /E:1024

in config.sys. This is probably a good idea in any case. Or (iii) edit all the configuration and/or batch files in emTEX to include switches that explicitly point to the search directories. (In emTEX almost everything is configurable in this way and can override the variables and defaults.) I do not recommend choice (iii).

Section 3. Customization

Now several things had to be done. I decided to postpone the installation of the beta test distribution and first get a working installation of emTEX configured to my system. I do not have a printer connected to my PC, so I need to have dvihplj (the LaserJet printer driver supplied with emTEX) print to a file. I made a copy of prthplj.bat calling it texpr.bat. It contained the two lines:

    @echo off
    dvihplj @lj.cnf /po=prn %1 %2 %3 %4 %5 %6 %7 %8 %9

and I changed the ‘/po=prn’ to ‘/po=%1.hp’. Now the command

    texpr foo

will cause the driver dvihplj to read in foo.dvi and produce foo.hp. This can be taken to the room across the hall and ‘copy /b foo.hp prn’ will produce the output.

I also wanted to make use of the feature of emTEX that the editor will be automatically called after responding ‘e’ to an error prompt in TEX. I created a batch file ‘tex.bat’ which contained the four lines:

    @echo off
    IF EXIST editor.bat DEL editor.bat
    tex286 /a=editor.bat &plain %1 %2 %3 %4 %5 %6 %7 %8 %9
    IF EXIST editor.bat CALL editor.bat

(This uses the slightly faster tex286 instead of the standard version tex.exe which I deleted, but ‘tex foo’ will have the same effect. Do this ONLY if you have a 286 or higher processor.) I did the same with latex.bat, replacing ‘&plain’ with ‘&lplain’ in the above. (In this one case I actually modified an existing file without renaming it. But there really is no better name for the batch file that calls L^{A}TEX than latex.bat.) Then I added to set-tex.bat the line (NOTE: this is highly dependent on your choice of editors. I use QEdit):

    SET EMTEXED=q %%2 /n%%1

Now when set-tex is called, the variable EMTEXED is set to ‘q %2 /n%1’ and if, for example, I say

    tex foo

and an error is encountered at line 45 and I give ‘e’ as a response to the error prompt in TEX, then emTEX will create editor.bat containing the line

    q foo.tex /n45

(Actually emTEX includes the entire path as well as the filename.) Then calling editor.bat will bring up QEdit with the foo.tex loaded and the cursor positioned on line 45. In the template EMTEXED, the %1, %2, and %3 (if present) are replaced by the line number of the error, the named of the file currently being input, and the name of the .log file, respectively. I tested this by issuing

    latex sample

and then

    tex sample

The latter had to produce an error since the command \documentstyle is unknown to plain TEX. It worked. (However, later I have found the line number to be sometimes off by one or two, as if either the editor or TEX miscounted. More likely they disagree as to what constitutes a ‘line’.)

Another thing I changed is v.bat (creating a file vr.bat— ‘r’ for ‘reduced’) by adding the switch ‘/o4’ to the call to dviscr in v.bat. This scales the screen output down by a factor of 4 so that the width of a complete page just fits on the screen. The print is somewhat small but readable. For narrow pages (standard L^{A}TEX article or book style) I can hit the gray + key once to get more readable text that still fits on the screen.

A comment here about screen fonts. A number of people have suggested that special screen fonts (say 108 dpi or so) would give the best quality display. emTEX uses 300 dpi fonts (using the LaserJet libraries lj_*.fli already mentioned). This means on a screen with 640 by 400 dots you can display about 2 inches of your document (against 6 inches with 108 dpi). This is provided for in emTEX with the /o switch. This causes the output to be reduced using gray scale mapping (that is /o3 causes a 3 by 3 square of black and white pixels to be replaced by a single pixel with a level of gray proportional to the relative number of black pixels.) This actually gives (in my opinion) better quality display than a 108 dpi font, by reducing the jaggedness of slanted lines. It slows the display down, but on my machine (a 25Mh 386) it is hardly noticeable (at least not after upgrading to version 1.4s of dvidrv) except for /o5 and /o7. An optimal trade-off (again, in my opinion) of speed versus quality is provided by 180 dpi fonts and /o2. This requires obtaining the p6l_*.fli font libraries and editing v.bat (or a copy) to replace ‘@lj.cnf’ with ‘@p6l.cnf’ and adding /o2 to the line in v.bat. You should only do this if you have another need for the 180 dpi P6L fonts (say a dot matrix printer). Or you can generate only the fonts needed if you upgrade to version 1.4s of dvidrv. See §7.

Before ending this session I added the line ‘call set-tex’ to autoexec.bat, deleted some of the OS/2 specific files (namely C:\emtex\*.cmd and C:\emtex\texp.exe), and edited set-tex.bat to include a few of my work directories in the search paths (and removing the items like ‘C:\mytex’ provided as examples).

Section 4. Installing the betatest; remaking the formats

Since I have 386 PC, I decided to install the beta test version, tex386, so as to have a TEX which had a big capacity as well as being very fast. I also decided that it might be appropriate to include the beta test of the regular (small) version. I don’t know if that was necessary, but in case of trouble with memory managers (not yet installed) I would have a TEX to fall back on that was the best yet available.

Thus, I put the disk containing tex386b8.zip and texb5.zip in drive A: and, from the root directory of C:, I issued the command

    pkunzip -do a:tex*.zip

Then I had to delete tex286.exe and, in the batch files tex.bat and latex.bat created before, I changed ‘tex286’ to ‘tex386’ (The file tex386.exe is the 386 specific executable. There is also a tex186.exe for “186 or above.” It is not a big TEX.) Unfortunately, now the format files (c:\emtex\texfmts\plain.fmt and c:\emtex\texfmts\lplain.fmt) would not work with either tex186 or tex386. One would get either the ‘can't find format...’ message or the ‘Fatal format error’ message. I needed to generate the formats with INITEX.

My first choice was to create the small formats (for tex186) even though I did not intend to use it much (I guess this shows a certain perversity). I changed to the directory C:\emtex\texfmts and issued the command

    tex186 /i plain

This presented me with several messages and then the TEX ‘*’ prompt. I typed ‘\dump<enter>’ and it was all done: I had a new format for plain TEX, plain.fmt. Almost the same command (‘plain’ replaced with ‘lplain’) produced (after a slightly longer time) the L^{A}TEX format file, lplain.fmt.

I think maybe it is a good idea to explain what happens when the above command is issued: Calling tex186.exe (or any of the versions of TEX provided with emTEX) with the ‘/i’ switch informs the program that it is to become INITEX. INITEX reads in plain.tex (which it finds in the directory C:\emtex\texinput because that is the default directory for inputing .tex source files). The file plain.tex consists of initializations of parameters, preloading of fonts, and definitions of macros which INITEX processes and stores in its memory. As part of this process, it must read the .tfm files found in the directory \emtex\tfm and the file tex.poo found in \emtex\texfmts. When all this is done, INITEX prompts with a ‘*’ for any additional commands you wish to add. The command ‘\dump’ tells it to store this memory in a file (named plain.fmt). It puts this file in the current directory (which I made sure was the right one). Now, when the command ‘tex186 &plain foo’ is issued, tex186 will search the default format directory (\emtex\texfmts\) for plain.fmt and load the predigested definitions and initializations with minimal processing required. The reason for having to remake the formats is that a different version of tex???.exe can have a different memory organization and size.

Then I created the directory C:\emtex\Btexfmts (note the ‘B’) which big TEX’s (like tex386) search by default for their format files. After changing to this directory, I issued the same commands as before, except ‘tex186’ was replaced with ‘tex386’. A common error with installation of tex386 is the failure to generate the format, or to generate it, but put it in the wrong directory. I tested by TEX’ing a recent paper that had already TEX’ed correctly, but needed one modification for submission to a journal:

    c:\work>tex

<TeX start-up messages omitted>

    *\baselineskip20pt\relax
    *\input spcdbmo

All went well. And quickly! (To those who know: the \relax was not necessary in this case, but it could have been and it didn’t hurt either.)

Later I tested what I already knew: tex386 will not work with the DOS 5.0 lines

    device=C:\dos\emm386.exe noems
    dos=umb

in config.sys. It exits quickly with a message about VCPI required. Later, I intend to install 386MAX as a memory manager. I have received information that this can be made to work with tex386. I also understand that QEMM is supposed to work well with tex386. In working with DOS 5 or 6 it has been recommended to leave the ‘noems’ parameter out of of the DEVICE=emm386... line of config.sys, using only the ‘ram’ parameter. This allows emm386.exe to provide the VCPI services required by tex386, but ‘wastes’ 64K for a page frame (unless you need expanded memory emulation for some other program). One poster to emtex-user has submitted this config.sys line

    device=C:\dos\emm386.exe 512 ram

and it is what I now use. I confess that I don’t have any idea what goes on between tex386.exe and emm386.exe after that. In particular, I do not know if the 512K mentioned in this line is made available or unavailable to tex386.

Section 5. Installing AMSfonts

This is not specific to emTEX, except the parts about what directories to put the fonts in.

There are a couple of ways of acquiring AMSfonts. One way is to acquire the sources. This may be the best way, but since I had never used , I decided to get all the .pk files. These (as well as the sources) are at e-math.ams.org. There are a set of tar files in directory /ams (a separate tar file for each of several different resolutions) or one can find the individual font files in subdirectories of /ams/amsfonts (a separate subdirectory for each resolutions). I needed the 300dpi fonts. The tar file for that was about 4 megabytes and I have a quota of 3 megabytes in my University account, so I could not download it. Thus I was forced to download the individual files in three small stages.

    The fonts were in /ams/amsfonts/pk-files/300dpi where they have names like msam10.300pk. Such

a file gives a 10 point font at normal magnification for printing on a 300 dots-per-inch device. For magnified

printing of the same font you need msam10.329pk, msam10.360pk, msam10.432pk, . . ., and msam10.746pk

corresponding to \magstephalf, \magstep1, \magstep2, …, and \magstep5. This is the case for all the fonts msam5 through msam10. And the same is true for msbm*, eu* (the Euler fonts), wncy* (the cyrillic fonts), cm* (several cm fonts at point sizes missing from many distributions of TEX, including emTEX). To stay within my quota I first downloaded cm*, and ms*. After transferring them to floppies and deleting them from my account, I downloaded eu*, and then later wncy*. All from the directory 300dpi. If you need 180dpi fonts for a dot matrix printer, you would repeat all this in the 180dpi directory. I do not remember if there is a 360dpi directory, but this is what you would need for higher resolution printing on many dot matrix printers. There are also smaller point sizes intended for screen preview.

I forgot to downloaded the AMSfonts documentation (in directory /ams/amsfonts/userdoc) and the .tfm files (in /ams/tfm-files.tar.Z, or in a subdirectory of /ams/amsfonts) but ended up going back to get them later. I also downloaded amstex.tar.Z and amslatex.tar.Z, acquiring the files for AMSTEX and AMS-L^{A}TEX in compressed archived form. These I uncompress’ed, then un-tar’ed and transferred to floppies. (If you are unfamiliar with the programs uncompress and tar, you can find all the files in /ams/amstex and /ams/amslatex and subdirectories) By the way, the font files, when transferred to a PC via ftp, normally have their extensions .nnnpk truncated to .nnn alone.

Back at my PC, I created the directory C:\texfonts\pixel.lj\ and then seven subdirectories under

C:\texfonts\pixel.lj. These are C:\texfonts\pixel.lj\300dpi through 746dpi, corresponding to the

sizes of the fonts I had just acquired. These directories are named to coincide with the default paths in the configuration file lj.cnf supplied with emTEX (see below). (If you are willing to edit the .cnf files and know what you are doing, you can put these files anywhere.) Now, for each of the floppies containing the font files I issued a series of commands similar to

    copy a:\*.300 C:\texfonts\pixel.lj\300dpi\*.pk

this put all the fonts in their proper place. The .tfm files all were copied into C:\emtex\tfm.

To see the reason for these choices, let us take a look at v.bat, the batch file used to view .dvi files. (Note: this is the one supplied with version 1.4d of dvidrv which comes with emTEX. The beta test version 1.4s is discussed later.)

    @echo off
    dviscr @lj.cnf /fl=-1 /ocr=1 %1 %2 %3 %4 %5 %6 %7 %8 %9

Notice the ‘@lj.cnf’. That means the screen previewer dviscr.exe will read the file lj.cnf to determine the value of certain font options the program can accept. In lj.cnf we find (I have added line numbers for reference):

(1) % lj.cnf (300x300 DPI using LJ fonts)
(2) /pd=%DVIDRVINPUT%
(3) /pl=%DVIDRVFONTS%;lj_0;lj_h;lj_1;lj_2;lj_3;lj_4;lj_5a;lj_5b
(4) /pf=%DVIDRVFONTS%\pixel.lj\$rdpi
(5) /pg=%DVIDRVGRAPH%
(6) /r=300
(7) /rf=300
(8) /fs=1

Lines 2 through 5 tell the driver (dviscr in our example) that if it cannot find the appropriate file in the current directory it should search this path for .dvi files (/pd), fonts in libraries (/pl), fonts in individual files (/pf), and graphics files (/pg). Consider line 3. In §2 I reported that I had placed the font libraries lj_*.fli in C:\texfonts\ and then set the environmental variable DVIDRVFONTS to that directory. Line 3 says to use that environmental variable and look there for the named .fli files. Line 4 says to look for a subdirectory ‘pixel.lj’ of that directory and then look for a subdirectory of that with the format ‘$rdpi’. The driver replaces the expression ‘$r’ by the needed resolution. For example, if a .dvi file calls for cmr10 scaled 1200, then dviscr is told (via the /rf300 switch on line 7) that UNmagnified fonts should have resolution 300 dpi and therefore it should seek cmr10 with resolution 360 dpi (300 times 1.2). The expression ‘$rdpi’ is therefore replaced with ‘360dpi’ and the dviscr looks for cmr10 in the directory

C:\texfonts\pixel.lj\360dpi.

The conclusion of all this is that the .pk files should go in the directory into which I had just put them, unless I wish to edit this file lj.cnf.

The drivers in the standard version of emTEX (dvidrv 1.4d) expect font files to have either no extension or one of the extensions .pk or .pxl. In my first go around two years ago I kept the numeric extensions and the drivers could not recognize them, so I renamed them with no extensions. This worked. The .cnf files supplied with the beta test drivers (dvidrv version 1.4s) contain information which cause the drivers to search for only the extensions .pk and .pxl. Once again, if you know what you are doing, you can give them almost any extension you want, provided you alter the appropriate .cnf file. This leads us to rule number six:

(6) If possible, arrange your setup to agree with the expectations of the drivers.

How to determine this? Well, the documentation never mentions any extension except .pk and .pxl; so use one of those (even though other extensions do not seem to be ruled out). When there is doubt, it is better if the case you have in mind is explicitly mentioned in the docs. The documentation for dvidrv (dvidrv.doc) is quite long and involves descriptions of what seem like hundreds of options. It is not possible to read it only once and comprehend it. However, reading it once will at least make searching it easier when you later go to it for specific information.^{3}

At this point the font files are installed. I use them as I would any other font files. To make it automatic, I would need some files from the AMSTEX distribution.

Section 6. Installing AMSTEXand AMS-L^{A}TEX (and the NFSS)

The amstex.tar file came un-tar’ed into a directory tree that matched the one on e-math: a directory amstex which contained some files plus a subdirectory doc. I preserved this structure when transferring to floppies and now I copied the doc directory (plus one file amstex.bug) into C:\emtex\doc, the other files

into C:\emtex\texinput.

To create the AMSTEX format a file amstex.ini is provided (it now resides in my C:\emtex\texinput directory) to be processed by INITEX. The file amstex.ini contains only the lines

    \input plain
    \input amstex
    \dump

After

    tex186 /i amstex.ini

(in the directory c:\emtex\texfmts) and

    tex386 /i amstex.ini

(in the directory c:\emtex\Btexfmts) I had appropriate small and big versions of the format amstex.fmt. Recall that I had installed the beta test versions tex186.exe amd tex386.exe as my small and big versions of TEX.

I then created a file amstex.bat in directory c:\emtex similar to tex.bat and latex.bat:

    IF EXIST editor.bat DEL editor.bat
    tex386 /a=editor.bat &amstex %1 %2 %3 %4 %5 %6 %7 %8 %9
    IF EXIST editor.bat CALL editor.bat

3 It should be gone to whenever you begin to say “I wish I could do…” Chances are you can.

(I needed to have set the environmental variable EMTEXED to use the /a switch.) Now I can TEX an AMSTEX

document foo.tex with ‘amstex foo’.

To use the AMSfonts under AMSTEX, I can simply use the command \documentstyle{amsppt}, which also loads the amsppt.sty. (If you do not like this style, or you do not want to use AMSTEX, you can use the files amssym.def and amssym.tex under plain TEX. Read the documentation (userdoc.tex) as to how this would be done.)

AMS-L^{A}TEX requires the New Font Selection Scheme (NFSS). AMS-L^{A}TEX is not really a new format, it is simply L^{A}TEX (with the NFSS installed) and with a few additional .sty files (amsart.sty, amsbook, etc.). And with (possibly) AMSfonts installed. Thus you do not need separate format files, you simply create a format for L^{A}TEX+NFSS and use ‘regular’ L^{A}TEX or AMS-L^{A}TEX via the appropriate \documentstyle parameters. (One minor problem, if you create the L^{A}TEX format with the AMSfonts preloaded—as I did, below—some L^{A}TEX commands for math symbols [like \mho] are undefined, you need to use their AMSfonts replacement. This may cause portability problems in both directions. If this is a worry, omit the installation of AMSfonts and load them when needed via the style file amssymb.sty.)

I decided to keep around the old L^{A}TEX (i.e., without the NFSS) to avoid problems with L^{A}TEX documents that assume the conventions of lfonts.tex (the OFSS). To do this I simply renamed lplain.fmt

to olplain.fmt in both c:\emtex\texfmts and c:\emtex\Btexfmts. In case of such a document I could

issue the command ‘tex386 &olplain foo’.

The amslatex.tar file came apart into several directories: One contained a copy of L^{A}TEX (for those who did not already have it). I deleted this. The others were ‘inputs’, ‘fontsel’ and ‘doc’ which contained necessary input files, files for the NFSS, and documentation, respectively. As usual everything in the inputs and fontsel directories went to c:\emtex\texinput, the doc directory went to c:\emtex\doc. Following the documentation, I changed the name of lfonts.tex to lfonts.old and then moved to the directory c:\emtex\texfmts first and issued the command ‘tex186 /i lplain’. When TEX complained it could not find file lfonts.tex (because I had renamed it) and requested another name, I typed ‘lfonts.new’. This file \input’s several nonexistent files, giving me the chance to somewhat customize the format. In place of ‘fontdef.tex’ I gave it ‘fontdef.ams’ because I wanted the AMSfonts to be accessible. In place of ‘preload.tex’ I gave it ‘preload.med’ (fearing a small TEX would suffer from ‘preload.max’). Finally, in place of ‘xxxlfont.tex’ I gave it ‘basefont.tex’ for ease of use of the AMSfonts.

I tried to repeat the whole thing in c:\emtex\Btexfmts with one change: After ‘tex386 /i lplain’ and when it came time to give a replacement for ‘preload.tex’, I tried ‘preload.max’ instead of ‘preload.med’. This led to an error message about ‘misplaced tab character’ when preload.max was \input. I looked into the file preload.max and it seemed that the problem was due to some chicanery with \endlinechar=`\&, but I was not able to quickly see how to remedy the problem. So I repeated the building of the format using only ‘preload.med’. This works fine to date. There is perhaps a bug in the file preload.max in the version I have. I do not know if there is a fixed version, but I got it from e-math in February (1993) and who knows when they got it, so readers are advised to consult the comp.text.tex FAQ or D. Jones’ TEX-index^{4} for a host with the most up-to-date version of the NFSS.

I had no problem TEX’ing the documentation provided, with one exception. That is nfss.tex, containing an explanation of the NFSS. (This is not required for installation. In fact it is somewhat out of date on the subject of installation, but it contains helpful information for using the scheme.) The problem was twofold: (1) It \input’s ltugboat.sty and tugboat.cmn, but even though I had those files (check the TEX-index for likely sources) I still got several errors. (2) It requires two fonts (cmss8 scaled 875 and cmssbx10 scaled 900) that the drivers couldn’t find (because I didn’t have them at those magnifications).

Problem (1) turned out to be due to the following lines in nfss.tex:

    \documentstyle[array%
    %      ,concrete% Uncomment this line if you have the euler fonts.
           ,ltugboat% Comment out this line and scroll errors if you
           ,newlfont% don't have the ltugboat option.
           ]{article}

4 You can acquire the TEX-index from most TEX archives. The CTAN hosts have it in directory help, along with the FAQ.

The problem is that ltugboat.sty tries to \input article.sty (after it was already \input). This can probably be corrected by editing nfss.tex so that the lines read:

    \documentstyle[array%
    %      ,concrete%
           ,newlfont]{ltugboat}

But I corrected it by commenting out the line in ltugboat.sty:

    \input article

since I happened to have that file in my editor when I recognized the problem. (I returned ltugboat.sty to its initial state afterwards.)

I solved problem (2) in two ways. The second one was to install the beta test of dvidrv 1.4s and use it’s automatic font generation feature. That was not without it difficulties (see §7). The first way was to use the drivers’ font substitution feature. This can be done either through a font substitution file (but I found the documentation of that feature somewhat confusing and I just wanted a quick readable version of this one document) or interactively: when the driver prompts for a new font, you type in the new name and resolution. Unfortunately the documentation (dvidrv.doc) was not clear on the best way to do that. It SEEMS to imply that you should type a new name OR a new resolution but not both. This may be correct for version 1.4d, but is not for version 1.5s.^{5} Here is what I did: I entered ‘vr nfss’ (recall ‘vr.bat’ is my revision of v.bat) and the driver dviscr said

    ...
    Loading font cmss8 scaled 875
    Warning 1205:  font cmss8 [cmss8<262.5>] not found
    Enter new font name/size:

I wanted to substitute ‘cmr7 scaled 1000’. I typed in ‘300<enter>’ indicating I wanted 300dpi resolution instead of 262.5dpi and it loaded the font cmss8 from the 300dpi directory. This is not what I wanted. So I bugged out (pressed Ctrl-C) and tried again. This time I typed ‘cmr7<enter>’ and I got this message:

    Warning 1205:  font cmss8 [cmr7<262.5>] not found

because I don’t have any 262.5 dpi fonts. Then I typed ‘300<enter>’ and all went well.

Section 7. Installing DVIDRV 1.4s (beta test). Automatic font generation, and .

Installing the beta test (in the sense of putting all the files into place) is as easy as installing the rest of emTEX. The download to a PC truncated the filename dvidrv_14s.zip (or something similar) to dvidrv_1.zip. I put the floppy with dvidrv_1.zip on it into drive a:, changed to the directory c:\ and issued the command

    pkunzip -do a:\dvidrv_1

and all files were copied into place. This overwrote a number of the .cnf files because, while the .cnf files give the drivers almost the same information as before, they provide that information in different format. This caused me no problems except that the drivers consistently complained about not being able to open the file lj_sli.fli. This is the font library of additional fonts for SLITEX, which I do not have. I could live with this complaint, but since I happened to know how to get rid of it, I did. This merits a little explanation.

Below is a copy of the file v.bat that comes with version 1.4s:

    @echo off dvidrv dviscr @lj.cnf /fl=-1 /ocr=1 %1 %2 %3 %4 %5 %6 %7 %8 %9

5 After posting to the emTEX discussion list I learned that in version 1.4s the 2 steps can be combined: ‘cmr 300<enter>’ will work, but I couldn’t find this in the doc’s. After the preliminary (ascii) version of this article came out Eberhard Mattes pointed out the relevant lines in dvidrv.doc. They are there, after some preliminaries that still leave me in a confused state. :-)

What I want to focus on now is the ‘@lj.cnf’ which again causes the driver to read from ‘lj.cnf’ for the values of its options. Here is the new lj.cnf (the line numbers are added only for reference):

(1) % lj.cnf (300x300 DPI using LJ fonts)
(2) /pd={,$DVIDRVINPUT:}@i
(3) /pl=$DVIDRVFONTS:lj_{0,h,1,2,3,4,5,sli}
(4) /pf=$DVIDRVFONTS:pixel.lj\@Rrdpi\@f{.pk,.pxl}
(5) /pg={,$DVIDRVGRAPH:}{@Rrdpi\,}@PBf{@Ef,.msp,.pcx,.bmp}
(6) /r=300
(7) /rf=300
(8) /fs=1
(9) /fm=hplaser
(10) /fd=2

Line (3) is the one I needed to change. Notice the change in syntax from the previous version: The environmental variables used to be flanked by ‘%’ signs. Here they are preceeded by ‘$’ and followed by ‘:’. Also there is a more compact representation of the font libraries: the common part ‘lj_’ appears only once and the appended endings are given as a comma delimited list enclosed in braces. Since I do not have the font library lj_sli.fli, I deleted the last choice in that list. I might point out the changes to line (4): What used to be ‘$rdpi’ is now ‘@Rrdpi’. This means ‘Round to the nearest integer the calculated resolution’ so it essential produces the same result as before. After that is appended ‘@f{.pk,.pxl}’ which means ‘look for the name of the font (the ‘@f’) given in the .dvi file, with either ‘.pk’ or ‘.pxl’ as its extension.’

There are also 2 completely new lines. They are related to the new feature available: automatic generation of missing fonts.

Since I intended to try the automatic font generation feature, I had to install MFJob and upgrade to the beta test of . After I put the floppy containing mfjob11l.zip and mfb1.zip into drive A:, I changed to the root directory c:\, and I issued the command

    pkunzip -do a:\mf*.zip

This was uneventful, as usual. I reasoned that the automatic generation of fonts would probably require the executable to be called mf.exe, so I copied mf386.exe to mf.exe.^{6} Being inexperienced with Metafont, I did not realize this was not enough. I changed to the directory C:\emtex\doc containing nfss.dvi and tried ‘vr nfss’ again. I again had to respond to the prompts about fonts not found (these can be turned off), but now I got a prompt at the end of the font loading phase that asked if I wanted to generate the missing fonts. I responded ‘y<enter>’ and then from the screen information it was clear that mfjob.exe was called, and then . But then there were messages (that I correctly presumed came from ) about not finding cmr.base and trying plain.base and not finding it.

What was going on here? Well, the line in v.bat begins ‘dvidrv dviscr...’ because dviscr is actually loaded by an auxiliary program dvidrv.exe. When fonts are missing, the information about them is written into a file. Then dvidrv calls mfjob.exe which calls and then gftopk.exe, giving them the appropriate parameters from that file. The resulting .pk files and .tfm files are copied to the appropriate directories (creating directories, if necessary), and then dviscr (or whichever driver) is recalled to process the .dvi, now finding all the fonts.

However, my couldn’t find its ‘bases’. So I looked for c:\emtex\Bmfbases and it didn’t exist. (This is where a Big like mf386 would search for a base.) I looked in c:\emtex\mfbases (where ‘small’ ’s find their bases) and there were cmr.bas and plain.bas. I then copied mf186.exe (the small from the beta test) to mf.exe. I tried the font generation again and got a ‘fatal’ error from and that phrase so familiar to TEX lovers everywhere: ‘I'm stymied.’ With TEX it usually means that the format file had not been regenerated after an upgrade so I decided that I needed to generate new bases (which by now I guessed must be analogous to formats in TEX). Fortunately,

6 Eberhard Mattes informed me that ‘set MFJOBOPTS=/3’ will cause MFjob to use mf386.exe. A feature of emTEX is that most of the programs can have options stored in environmental variables. That way, if the user is unable to specify an option in the usual way from the command line, (for example, if the program is called by another program) the option can still be passed along. in the mfbases directory is a file ‘bas.bat’. I looked into it and found it called ‘mf.exe’. I made two copies of bas.bat, changing ‘mf’ to ‘mf186’ and ‘mf386’, putting the first into the mfbases directory and the second into a newly created Bmfbases directory. Then I typed ‘bas<enter>’ in each directory and created new files cmr.bas and plain.bas in each. I recopied mf386.exe to mf.exe and tried ‘vr nfss’ in the C:\emtex\doc directory again and this time it went off without a hitch. Giving me two new directories

C:\texfonts\pixel.lj\263dpi and 270dpi containing one font each.