Gabe's LaTeX
Pages
Note: some stuff on this page is pretty out-dated,
e.g., xfig and eepic,
but unfortunately, I don't have the time to update the information.
WSCG style
For whatever reason, the WSCG conference
does not provide LaTeX style files so that LaTeX users could adhere
to their submission formatting standards easily. (IMHO, they are not the most
aesthetically pleasing anyway.)
The only thing they do provide is an M$-Word template (and a PDF generated from that).
So, here is my LaTeX package for the WSCG conference.
Instructions are at the beginning of the 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 package.
(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):
- mydocumentation.sty:
utility macros for writing pseudo code and pictures in the margin
(and a few others).
- mymath.sty: some math utilities
- mylayout.sty:
changes some parameters of the layout
- mypicture.sty:
convenience macros for including 2 or 3 pictures side-by-side (with
several variations). Works both iwth EPS and PDF.
- myalgorithm.sty: a few extensions to
and combination of the algorithm and the algorithmic packages from
CTAN. (IIRC, the return statement can now have a
parameter, I introduced a comment statement, I renamed the
STATE command into STMT, and i added an option
small.)
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:
- Run latex/pdflatex using a custom format file,
remaking the custom format file if necessary;
- Grep for errors, warnings, unresolved references,
or underfull/overfull boxes (i.e., filter out certain unnecessary
verbosity);
- Call dvips/dvipdfm
- 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:
- This will speed up latex a lot
- if you have a small document and at least a few \usepackage's, or
- if you have a lot of \usepackage's, or
- if your home and/or latex installation is on a remote server.
- This can reduce the "verboseness" of latex, which can help
during the early stages of a document.
- Convenience during the final stages of the document.
- 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 ;-)
-
Including eepic files by TeX is much faster
than including EPS pictures with psfrag on.
-
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.
-
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.
-
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.
-
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.
-
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:
-
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.
-
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?
-
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 ).
-
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:
-
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.
-
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:
- in xdvi, filled white rectangles don't hide other objects behind
(in PDF output, everything is ok)
- rotated text doesn't show rotated
- "Too many points" made xdvi exit
(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:
Thu Aug 10 12:11:37 MDT 2017