Gabe's LaTeX Pages

WSCG style

For whatever reason, the WSCG conference does not provide LaTeX style files so that LaTeX users could adhere to their submission format standards. (They are pretty ugly anyway.) The only thing they do provide is a M$-Word template (and a PDF generated from that).

Anyway, here is my LaTeX style file for the WSCG conference. Instructions are at the beginning of the style file. It loads a few other packages, but most of them should already be on any decent LaTeX distribution. There are a few packages of my own that you might find useful; yo can download them below (Section "My little latex macros").

In addition, here is a boilerplate LaTeX file that shows how to use the WSCG style file. (If you run this as-is through latex, it will complain about some files not being found (graphics), but that doesn't hurt.)

To generate PDF, just run pdflatex paper.tex. Include vector graphics (drawings) as PDF, and bitmap graphics as PNG. Make sure that the PDF file contains all fonts as so-called Type-1 fonts; you can check that either with AcroRead (File / Document Properties / Fonts / List all fonts), or, under Linux/Unix using the tool pdffonts that comes with xpdf.

Getting started with LaTeX

This is a very short and simple Latex document for beginners who need a quick-start. It contains, hopefully, almost all of the basic Latex commands you'll need for writing a simple document: titles, headings, cross references, citations, bibliography, figures (single and side-by-side), and umlauts.
Just open it with our favorite ascii editor to see which latex-command does what.
You'll need most of the style files listed below containing macros I found quite useful (see below). You can also download the whole example directory (example.tar.gz) (example.zip) which contains everything you'll need to typeset the example document, including a Readme file. Just get one of these archives, unpack it, follow the 8 steps in the README file, and viola, you created your first latex document, with figures and everything!
Well, I assume you've got LaTeX2e, caption.sty, and a few others (like graphicx.sty) which should be in your LaTeX2e distribution. Known problem (thanks to Harriet Lord for pointing it out): it might be possible that you need to remove the line \usepackage[T1]{fontenc} from documentation.sty (that won't hurt, it just means that LaTeX won't be able to hyphenate words containing umlauts etc.).

My little latex macros

Over the years, I wrote some LaTeX macros (and collected some):

Converting between LaTeX and HTML with vim

Those among us who write their Latex documents with vim might want to check out some simple vim macros for converting between Latex and HTML back and forth.

Yet another LaTeX to HTML converter

yal2h is my little perl script for converting LaTeX to HTML. (Actually, it was written by my research assistant Andreas Flick, I just modified it further.) It works for me, YMMV. It is very simple, it has almost no options, and it can produce only one single HTML file. But it can handle \include's and it can handle several of my personal macros (like the side-by-side figure macros).
It requires perl 5.005. As with all scripts, you need to change the very first line of the script and insert the path where Perl lives at your site.
Usage: yal2h [options] file.tex > file.html

Reducing turn-around time of LaTeX

This little wrapper script, ltx, can do the following for you:
  1. Run latex/pdflatex using a custom format file, remaking the custom format file if necessary;
  2. Grep for errors, warnings, unresolved references, or underfull/overfull boxes (i.e., filter out certain unnecessary verbosity);
  3. Call dvips/dvipdfm
  4. Start a viewer, or notify the viewer if already running, so that it pops up to the front and reloads the dvi/ps/pdf file.
Reasons:
  1. This will speed up latex a lot
  2. This can reduce the "verboseness" of latex, which can help during the early stages of a document.
  3. Convenience during the final stages of the document.
  4. Convenience, too, especially when run from an editor.

Basic usage:
ltx file Run latex, create custom format file if necessary, filter everything but errors
ltx -x file dito, and popup/start dvi viewer xdvi
ltx -x -p file dito, but popup/start postscript viewer gv

More explanations are given in the comments at the top of the script, and with ltx -h.
The script is a ksh script and has been tested with teTeX-1.0 under IRIX (SGI's Unix).
It should run on all other Unices with teTeX 1.0 or higher. Of, as with all scripts, you might need to change the very first line so it points to where ksh lives at your site. If you don't have ksh, you can try to stick in the path of bash.
You might need another little helper script, csh2ksh, or you can just remove the lines starting with "tex variables set already?" from ltx.

Joining lines broken by bibtex

Bibtex breaks long lines (i.e., > 80 chars) and protects the linebreak with a %. This is not a problem in usual bibliography entries, but with \url's or \path's, it is a problem.
So I wrote this little wrapper script btx which runs bibtex, then joins all lines in the resulting .bbl file which end with %.
% characters in the middle or beginning of a line will be retained.
As a little bonus, it also filters out annoying warnings, like "empty publisher".
Usage: btx blub.
Requirements: you need Perl.

How to do it without psfrag

Here is my humble advocacy concerning psfrag.
You wonder what psfrag is for? Ok, here is what you've been missing:

In your drawings or plots, the font should be the same as in the text block (or compatible with it). In addition, you will want LaTeX to do the typesetting of any text in your drawings/plots. (If you never have any text in your drawings/plots, then the following is not of interest to you.)

There is a package psfrag, which makes LaTeX typeset the text within EPS files. (Restriction: it can either replace only the text enclosed by \tex{...}, or it can replace only the text specified by a certain mapping in the LaTeX file.)

So far, so good (well, besides that restriction). But, when you want to produce PDF, you will realize that psfrag doesn't work with PDF. Period.

For the past few years, I've been using psfrag for all my line art, which I produced almost entirely with xfig and gnuplot. Then, I switched to use eepic macros (no EPS any more). Since then, I have switched to pslatex. They don't offer all the advantages of eepic (see below), but they offer the complete xfig feature set.

IMHO, the eepic format has a lot of advantages over EPS+psfrag. Even if you don't use psfrag, there are cases when you might want to switch to eepic. (I had to add a few features to the eepic export of xfig and gnuplot, of course ;-)

  1. Including eepic files by TeX is much faster than including EPS pictures with psfrag on.

  2. They work exactly the same way whether you produce Postscript or PDF. There is no need to write different wrapper macros (if you have wrapper macros like I do), and there is no need to convert EPS to PDF.

  3. You see the figures in xdvi, too, without xdvi having to start an external helper program (like ghostscript). So previewing with figures on is faster.

  4. The figures are really included in the dvi file, they are not just referenced as with eps. So you could actually send the dvi file to somebody else, or put it on the net.

  5. The font sizes you choose in your xfig drawing (or gnuplot graphs) will be the actual sizes in the output from LaTeX. This is, IIRC, not true when using psfrag. With psfrag, you have to write \\small & Co. within your drawing's text, which makes it hard to position the text in the drawing.

  6. With multiple EPS or PDF figures in one document, the same PS/PDF header is included in the final PS/PDF file multiple times. In my case (about 200 plots and drawings), this accounted for about 600k of the final 2.5M PDF file (25%!). This is, of course, not a problem when you just print the document yourself, but it is a problem when you want to put that file on the internet.

Remarks:
  1. From a software-engineering point-of-view, I think having 1 file format is better, instead of saving things which really belong together in different files, which is what the 'pslatex' file format does. Besides, the 'pslatex' route doesn't have advantages 2,3,4, and 6 described above.

  2. Advantage 2 from above seems like a weak argument; after all, automatic conversion from EPS to PDF can be done by writing a makefile. But I am sure there are quite a few LaTeX users who will not want to learn makefiles. Plus, not having to think about any conversion is nicer, isn't it?

  3. If you do not use xfig/gnuplot for your line art, but some other program which cannot export eepic, then you can still sometimes use this approach: you export postscript, and then convert that into xfig format via pstoedit, and then you can convert from xfig format to eepic with fig2dev (which can be obtained from www.xfig.org ).

  4. I haven't tried the eepic approach under MikTeX, but I do know that there is a gnuplot port for Windows; and there is a xfig reimplementation under Java, which I have actually tried successfully under Windows.

Things to keep in mind when inluding line art via the eepic route:
  1. You should draw the figure with its true size. Back when I included figures as EPS files, I used to have \includegraphics scale it for me to the \textwidth (or 0.5\textwidth). The disadvantage is: when your figure contains some text, then you get a different font size in each figure, because the scaling is probably different for each figure. This is bad typography.

  2. If you want to use a lot of the shading features of xfig, you might want to check first that 'fig2dev' can export everything all right. I seem to remember that the eepic export of fig2dev had some limitations. (My figures are mostly plain line art, so I haven't had any problems.)

Problems with eepic & xdvi:

(I had to add some features to the eepic drivers of xfig/fig2dev and gnuplot, but by now they are incorporated in the current xfig release.)

Gabriel Zachmann
Last modified: Wed Aug 02 12:29:47 MDT 2006