Generating PDF files from TeX  

NSF is now requiring PDF files for grant submissions. Science many scientific departments do all documentation preparation using TeX, it has now become important to know how to produce PDF files from TeX.

Unfortunately there is no perfect alternative, and the best current alternative requires you to spend money.

There are a number of problems:

• By default, TeX uses bitmapped fonts. PDF files are intended to be usable on the screen, and on any printer. If you use the default of 300 dpi, the results don't look good on the screen, nor do they make proper use of 600 dpi printers. Furthermore, due to an apparent bug in acroread, printing from the PDF file doesn't seem to work at all. This problem can be fixed by using Native Postscript fonts (i.e. Type 1 fonts). Such fonts are available.
• A number of people have tried to use ps2pdf, a utility that comes with Ghostscript, to produce the PDF file. If you use Type 1 fonts, it will represent the text as images. This actually works, but it produces e n o r m o u s files. However they do print properly.

The only alternatives that give proper output involve using Type 1 fonts. To install Type 1 fonts for use by dvips, see /rutgers/ref/ru-dist/tex-type1. Look at README in that directory.

Once you've installed them, you have your choice of three approaches to generate the PDF file.

• ps2pdf. At least with the version in Track, which is Ghostscript 4.03, ps2pdf, this will work, but it will produce an e n o r m o u s PDF file. If you print from the PDF file it will produce an e n o r m o u s Postscript file. For example, a fairly typical TeX file (25 pages of output) took 50K in .tex, 74K in .dvi, 1.3 M in .ps, and it produced a 4 M PDF file. When I printed the PDF file, I got a 13.5 M Postscript file, that took 15 minutes to print on a big HP printer. But the printed output looked OK, although because of the usage of images, it didn't use the full resolution of the printer.
• The Adobe Acrobat Distiller. This is available for about $47 from www.software.net and PC Connection, assuming that you ask for educational pricing.
• pdftex. This is a replacement for tex, that produces .PDF files rather than .DVI files. Unfortnately it is not clear that it is stable yet. It is being done by a grad student. There are reports that the resulting PDF is not viewable on all Acrobat readers (e.g. the Mac). My reading of the documentation is that figures will have to be done differently than for dvips. More information is available at http://tug.cs.umb.edu/applications/pdftex/.

I would encourage people to experiment with pdftex. However it appears to me that the only safe approach at the moment is to use the following set of tools:

• Produce .dvi files with the usual TeX tools.
• Make sure that the Type 1 fonts are installed on your system.
• Use dvips to produce a .ps file.
• Use the Acrobat Distiller to produce the .pdf file.

This means that departments that want to produce .PDF files will need access to the Distiller. There is a copy on RCI. Thus you can move your files to RCI for conversion if you don't want to buy your own copy.

Use of Distiller

If you're not careful a subtle problem can occur: the individual documents look OK, but when NSF puts them together, the resulting PDF file is scrambled in some contexts.

To prevent this, invoke distiller with the following options:

distill -embedallfonts on -subsetfonts on -maxsubsetpct 100 FILENAME

Here's what this does:

-embedallfonts says to include all fonts used in the document (except the standard 13). You'd think this would be the default.

-subsetfonts says to include only the individual characters used, not the whole font.

-maxsubsetpct 100 says to subset all the time. By default, if more than a certain percent of the font is used, it will include the whole font. With this setting, it will always use the subset mechanism. (The manual says that the maximum value for this is 99, by the way.)

I think the default is probably embed, subset, and maxpercent something less than 100. So by turning up maxpercent to 100, you force all fonts to be subsetted, thus saving some space.

I believe the subset mechanism works differently than the full font mechanism. I suspect this is a bug workaround, forcing the the subset mechanism to be used all the time

Note that you can set default parameters for distiller, in the Startup directory. (Users can also have their own defaults.) The online distiller manual will explain this. I recommend setting these parameters to be the defaults.

I just installed Type 1 fonts: Why doesn't ghostscript show page numbers anymore?

After installing Type 1 fonts, one user observed that his documents no longer showed page numbers in Ghostview. The explanation is sort of interesting:

dvips tries to model the memory in the printer. If it thinks the document is too big, it breaks it up into sections.

If the document uses sections, it inserts a comment of the form

     %DVIPSSectionPage: 1

before every page. If the document does not use sections, it inserts a comment of the form

     %%Page: 1 1

before every page. The %%Page: comment is a standard EPS convention, which ghostview understands. The %DVIPSSectionPage: is not. Thus you won't see any pages in Ghostview if dvips breaks your document into sections.

It is reasonable to suggest that this is a bug.

Now, there are four ways to "solve" this (other than modifying dvips):

• write a little script that fixes the comments
• Run dvips with the -a option. This causes it to make an extra pass to optimize font usage. At least for this document, that saves enough memory that it doesn't need to break it into sections.
• Tell dvips that the printer has enough memory. You tell dvips what printer to use by the -P option. The amount of memory it thinks a printer has is set by /usr/local/lib/tex/ps/config.PRINTER. The default is config.ps. It is currently set to 400K. I think our printers are bigger these days. You might increase that. I tried this document (which was 600 pages) with 1M, and it worked. I haven't tried to find the exact amount.
• Tell users with documents like this to create .dvipsrc in their home directory containing a line

        m 1000000
  

  or whatever number turns out to be large enough. That will override the value in config.ps (though possibly not the printer-specific value if they specify a printer).

My suggestion is that you look again at your config.* files, and increase memory to more reasonable values.