Millennial Conference Proceedings
TeXnical Notes

TeX flavor

LaTeX, in its current incarnation, LaTeX2e, has become the standard in mathematical publishing, and virtually every publisher these days uses LaTeX. To use LaTeX, one has to specify a "documentclass", which determines general "look" of the document. To obtain a uniform appearance of the volumes, the same documentclass should be used for all articles. Natural choices would be one of the standard classes "article" or "amsart" (nearly all papers submitted in LaTeX were set in one of these classes), or a generic class for conference proceedings that the AMS has made available (among dozens of other specialized classes). In addition, major publishers like Springer or Kluwer have their in-house documentclasses and ask authors to use those classes.

Our publisher (A K Peters) requested that the "book" documentclass (one of the standard LaTeX documentclasses) be used, along with a style file they provided that customized some of the settings in the book class. Each paper was set as a chapter within the book class, but compiled individually, as a separate document.

Conversions from other TeX flavors

About two thirds of the papers were submitted in LaTeX. Of the remaining papers, one was submitted in Microsoft Word (which had to be essentially retyped from scratch), two were in plain TeX, and the rest (about two dozen altogether) were set in Amstex, with the amsppt documentstyle. Amstex is incompatible with LaTeX, and the conversion to LaTeX is a major task. Fortunately, the amsppt style is a highly structured style, and many constructs in amsppt are exact analogs of constructs in LaTeX. Thus, while the changes needed to convert to LaTeX are very substantial, they are of the type that can be automated, and I was able to largely automate the conversion process with a perl script I wrote for this purpose. The program worked nearly flawlessly on well-formed amstex/amsppt files, saving dozens of hours of manual work, but performed less well on poorly (in the TeXnical sense) written files and files that did not use, mis-used, amsppt constructs. However, this was to be expected: If an author uses a manual construct such as \centerline{\bf ...} instead of \section ... \endsection, say, to indicate a section heading, a program wouldn't be able to determine whether the \centerline{...} construct indicates a section heading, or something else, such as a displayed equation.

Marking-up of TeX files

In the pre-TeX era, mathematical documents were typeset from scratch by the publisher, using highly specialized (and expensive) software and equipment. This was a time-consuming, and expensive task. A common myth is that providing papers in TeX eliminates this step. While it is true that a properly formed LaTeX file can be used almost as is, with only minor modifications, I have also come across papers that are nominally in TeX or even LaTeX, but so poorly typeset that fixing up these papers would take almost as much time as retyping the paper from scratch.

Some of the papers we received were indeed perfect, or near-perfect, in this respect, though the majority required some degree of mark-up to correct typesetting problems, ranging from hardcoded structural items (such as theorems, section headings, citations, etc.) to cosmetic problems (such as setting long formulas inline instead of displaying these formulas). Most of this work was outsourced to a local freelance LaTeX typesetter.

Figures and tables

In areas such as geometry or topology figures play a prominent role, and can present significant technical obstacles. However, due to the nature of the subject (number theory), figures and tables were essentially a non-issue here. Only a handful of papers contained figures, all of which were provided as eps or ps files, the ideal format for inclusion in tex files. The figures were incorporated into the tex files using the graphicx or the epsfig package. (The graphicx package represents the state of the art in graphics inclusion, though the publisher preferred epsfig. I don't think it makes a difference one way or the other as the graphics we had to deal with weren't very complicated. Also, it is easy to convert from one form to the other.)

Some papers contained tables that had to be reformatted, or, in a few cases, split. While technically not difficult, getting tables to come out "right" (i.e., in an appropriate size, at a suitable place in the manuscript), can be a very laborious process, and there were cases where it took hours of fiddling with parameters and settings to obtain a satisfactory result.

Bibliographies

A significant amount of time was invested to create bibtex bibliographies for all papers. Doing so has a number of advantages over hardcoding bibliography items: The main downside to using bibtex is that creating bibtex bibliographies is very labor intensive. Also, the coding of bibtex entries requires some care as slight variations from the bibtex syntax may have undesirable side effects. A few such errors surfaced during the Galley proof stage; while these were trivial to correct, for authors not familiar with the bibtex mechanism these errors may cause unnecessary concern. For instance, if a multi-author item is not coded properly, it may end up getting alphabetized by the last author.

Downloading bibliography items from MathSciNet. I think the ideal handling of bibliographies would be to download bibtex references from a standard source such as MathSciNet. This would virtually guarantee the correctness of the bibliography items, ensure that the references are set in a standard format, and as an added bonus, provide MR citations which can be linked to MathSciNet reviews in case the volumes are published online. We have done this for some, but not all papers, simply because it would have been too time-consuming. The AMS now has tools to facilitate "batch lookups" in MathSciNet; those were not available at the time most of the work was done, but even with such tools a considerable time investment is required as bibliographies provided by authors come in all shapes and forms and are rarely in a form that is suitable for use in automated lookup tools.

Sorting of bibliography items. Bibtex automatically sorts bibliography items, regardless of the order in which they appear in the bibtex source file. In most cases, items are properly sorted, but occasionally minor errors in the coding of bibtex entries (e.g., omitting a pair of braces around an author) can change the sorting order in an undesirable way. Several such problems turned up at the Galley proof stage (which, however, were easy to fix with a single edit in the offending bibtex entry).

TeXnical note. One problem I ran into in this connection was that an "unpublished" item without a "year" field gets placed before other items by the same author, whereas it should be the final one of the bibliography entries for that author. I solved this problem by adding a "year = " line containing code that contained the year without actually displaying it:
year = {\setbox0=\hbox{2002} to appear}
This caused bibtex to sort the item is if it had a "year={2002}" entry, thus placing it after all items with earlier years. I am not sure if there is better way of achieving the same affect (other than through the bibliography style); in any case, the trick worked like a charm.

Incorporating bibliographies in tex files. The publisher requested bibliographies to be included in the tex files. Thus, after all bibliographies were in final form, the bbl files generated from these bibliographies were incorporated into the main tex files. (A perl script was used to do this wholesale on all 72 files.)

Compiling the volumes

The publisher originally requested that the entire volume be compiled as a single document, as one would do with an ordinary book. However, due to the highly non-homogeneous nature of the individual papers, this would have led to numerous conflicts among macros and labels for theorems, equations, citations, etc. Resolving such conflicts would have required investing a tremendous amount of effort in renaming hundreds of labels, while ensuring that no new errors are introduced in the process, and there was a very real risk of unexpected problems arising from more subtle, and hard-to-diagnose, conflicts. The main benefit of compiling the volumes as a single document is that the pagenumbering is automatic: If there is a change in the number of pages of one paper, then recompiling the file will automatically update all pagenumbers. However, with a bit of programming one can achieve essentially the same functionality when the files are individually processed. To automate the updating of page numbers, I wrote a perl script that takes as input a list of tex files in the order in which they are to appear, obtains the number of pages of each file from the corresponding log file, allocates a range of pages to the file (adding a blank page, if necessary to ensure that each paper starts on an odd-numbered page), updates the page counter for that file, and finally compiles all files with the updated page counter settings.

Galley proofs

To allow Galley proofing of papers, I posted postscript and pdf versions of the manuscripts to a temporary website, and sent an email to all authors with a request to download their paper from this website and report any corrections needed. The website was de facto password protected as one had to know its name to access it (and only the authors and editors were informed of this site). It was not linked from other websites and thus was invisible to search engines.

All authors were able to successfully download their paper from this site, so it was not necessary to mail out hard copies.

Creation of ps files. Ps files were generated in the usual way, with dvips. I did, however, pipe the ps files output by dvips through the "psdraft" utility to add a date stamp. This had the advantage that updated files on the Galley proof site can be easily recognized and distinguished from the original versions. This is important as most browsers tend to use cached versions of files if one tries to download the file again within the same session. In fact, in Netscape, the "Reload" button doesn't seem to work on ps or pdf files (or other non-html files), and (as far as I know) the only way to ensure that a fresh copy gets loaded is to either empty the cache explicitly or exit and restart Netscape.

Technical note. One problem surfaced when using psdraft to "date-stamp" files. It appears that psdraft interprets embedded postscript files containing graphics as separate pages and thus adds a date stamp to each figure. I don't know if this is just due to the nature postcript works, or if there would have been a way to get around it. In any case, this seemed to me a minor cosmetic problem that didn't affect the Galley proofing, and which wasn't an issue in the production of the final version since that version did not need date stamps.

Creation of pdf files. Pdf files were created in a single step from the LaTeX source files with pdflatex. This is the easiest, and most reliable, method to convert tex files to pdf. The main downside is that pdflatex does not automatically convert eps graphics. To obtain a pdf file that does include graphics one has to convert the eps files to pdf files using a tool such as epstopdf. This is a bit of a hassle, and since the graphics were properly displayed in the ps versions of the files, and the pdf files were temporary files, not intended for a permanent online publication, I decided to not bother with that extra step. For the vast majority of papers that did not contain figures it didn't make a difference anyway.

Making corrections and recompiling files. All relevant files (tex, bib, ps, pdf, etc.) were kept in the galley proof directory (website), and all work was done within this directory. I had a script "makegalleys" that runs latex, bibtex, dvips, and pdflatex, in the appropriate sequence, to update all files in a single step, after making a correction to the tex file. This allowed for efficient, and near real-time, implementing of changes/corrections I received from authors by email, and authors could immediately access the updated files and report any further corrections if needed.

Millennial Conference Proceedings: Production Notes

ajh@uiuc.edu