I find it useful to be able to switch the type of output LaTeX produces between PDF and postscript (once I get the hang of MathML then I might add that to this list). Most of the time this is purely a matter of using pdflatex instead of latex + dvips but with more complicated LaTeX documents then it is sometimes a little more involved. This is particularly the case where external graphics files are involved.

---

The basics are quite simple. The graphicx package solves most of this by allowing you to not specify the extension of the image that it is importing. It tries adding extensions until it finds one that exists or doesn't find one at all (you can override this behaviour by specifying an extension). You can customise the list of extensions, but there are some defaults that can be selected by passing the right option to the graphicx package in the first place. Thus if you have image files

image.pdf        image.eps

then the following will include the pdf one:

\usepackage[pdftex]{graphicx}
...
\includegraphics{image}

whilst this will include the eps one:

\usepackage[dvips]{graphicx}
...
\includegraphics{image}

This appears to be simply shifting the problem as we still have to pass a different option to the graphicx package. Fortunately the package ifpdf comes to our rescue. This is part of the teTeX distribution or can be downloaded from CTAN. It defines a new 'if' which is true if we're using pdflatex and it is producing PDF output (it is possible to use pdflatex but produce DVI output). Thus the following will work in all circumstances.

\usepackage{ifpdf}
\ifpdf
  \usepackage[pdftex]{graphicx}
\else
  \usepackage[dvips]{graphicx}
\fi
...
\includegraphics{image}

So far, so good. But XFig throws a spanner into the works here. Most of the pictures that I import are XFig pictures and include LaTeX labels (using the "special" tag). Therefore I export them in pstex/pstex_t format. The problem with this is that the image file is now definitely postscript and the line which includes it into the document has the extension hard-coded in. To fix this, you need to convert the postscript to PDF and fix the hard-coding.

Fortunately there's a quick way to do all of that. Rather than exporting the picture from XFig, save it in the native XFig format (extension .fig) and run the following commands:

fig2dev -L pstex [image].fig [image].eps
fig2dev -L pdftex [image].fig [image].pdf
fig2dev -L pstex_t -p "[directory]/[image]" [image].fig [image].pstex_t

Obviousely, change [image] to the name of the picture. Change [directory] to wherever you put your pictures, relative to where the main LaTeX document is. The program fig2dev comes from the package transfig and is available on just about every system I've ever seen (including MacOSX via fink). Finally, just input the pstex_t file into your document:

\input{[image].pstex_t}

To automate all of that, download this little script. Run this script when in the directory containing your figures and it will do the above on all of them. It is written as a zsh shell script and assumes that zsh is in /bin. It assumes that you keep your pictures in a subdirectory called figures.

Note 1: to get PDF output from fig2dev you need ghostscript and ps2pdf installed. I guess that what it does is generate the postscript version and then convert it to PDF. Thus if you don't have ghostscript or ps2pdf (which comes with ghostscript) then you could use some other facility to convert the postscript version to PDF. However, all of the above is fairly standard on a UNIX distribution, including MacOSX via fink.

Note 2: the script above isn't quite the one that I use. I allow for a more dynamic approach to where I put the figures. When I have a document which has figures in it then I define a macro \figdir to point to the location of these figures. So the last line of fig2pstex in my version is:

fig2dev -L pstex_t -p "\\figdir/${fig:r}"  ${fig:r}.pstex_t

and my input line reads

\input{\figdir/[image].pstex_t}

Update: Fink and Epsfig

The default version of transfig shipped with fink uses epsfig rather than includegraphicx. However, epsfig is merely a wrapper for includegraphicx provided for backwards compatibility with psfig. Therefore, despite the name, epsfig can still work with non-Postscript files. So the above should work as is for the default transfig installation on fink. Of course, in the long run it would be better to reinstall transfig to use includegraphicx directly rather than via epsfig.