This means lines of LaTeX referring to images, for example, will likely come in pairs:
\includegraphics{Example.eps}}
%\includegraphics{ExampleBW.eps}}
If I wanted to print out a (paper) rehearsal slidesheet, I would have
to go back through my .tex file and switch the comments
on pairs like that. This gets to be a pain for large numbers of
images or for cases where the respective lines don't come in pairs,
such as for the University of Chicago logo we often put in next to the
title slide (but omit for black and white versions):
\begin{slide}
\begin{center}
% UOFC LOGO GOES HERE %BW
\resizebox{7in}{!}{ %color
\includegraphics{uofc.logo.lg.slide.eps}} %color
\end{center}
\end{slide}
Note the comments I have added at the end of the respective lines
though. modline looks for lines matching particular
patterns (like comments of a certain format) and performs a specified
action on the matching line (like commenting or uncommenting it):
modline 'COMMENT=%color$' 'UNCOMMENT=%BW$' example.tex
See usage for more details.
modline.
Basically the idea was to have a program which acts on a file like
[x]
emacs's
function query-replace, but using
perl's regular expression
syntax (with which I am slightly more familiar). (Okay, I'll be honest
here, I lost patience trying to figure out how to get "."
to match newlines.) This could really use something like curses, of
which I have no knowledge, and so I almost didn't include it here; it's
more of a toy that I'm no longer experimenting with rather than a tool
that I've finished making.
modline, when preparing
slides it's often convenient to print up rehearsal sheets with the
slides fit, say, six or eight to a page. Angus Duggan's utility psnup
(no link here since this seems widely available on unix, and I could
not locate a definitive central source) is well-suited to this
task. Unfortunately I couldn't seem to get the output format to look
quite the way I wanted, mainly because of some peculiarities in our
slide setup. I wrote this as a sort of workaround, to produce formatting
closer to what I wanted; but as I say in the usage statement, this is done
in a rather "goofy" manner. Consider yourself warned.
NEW option, -I, orders slides right-to-left instead of
left-to-right; I have found this useful for poster rehearsal sheets
(the upper right corner of your sheet is the upper left corner
of the poster).
\signature{} environment in the letter,
but this can be overridden with the -f flag. That is, the
argument after -f is the new name to put on the envelope
above the from address. The from address is taken from
the \address{} environment, and the recipient name and
address are assumed to be contained in the \begin{letter}{}
environment.
The rough draft I wrote of this used a very trivial regular
expression to extract the contents of an environment (effectively
/{(.*?)}/). This obviously would break if you had nested
environments or literal braces (i.e., braces escaped like '\{'
or '\}'). I tried to fix that in this version, and hopefully
haven't made something that breaks in worse ways.
perl code, so you are
entirely at your own risk here. This program was written by Matt Kupinski
using my function Parse_rule. (You can think of
ApplyRule as a sort of grep which uses
perl code instead of regular expressions.)
vm. I am
quite happy with its power and customizability, but unfortunately here
at work I am running an older version which does not really grok
MIME; upgrading
vm would also involve upgrading [x]emacs
itself, which is more of a hassle than it would be worth (to me or my
sysadmins) right now. I later discovered that all of this could be
accomplished in a couple of lines of perl using its
built-in uuencoding support with pack and
unpack, but what the heck, I learned a bit about MIME.
:)
These two programs understand only base64 encoding; any other MIME
attachments are ignored. To use enmime in
vm, I type:
M-1 M-! enmime <filename> [...]
(M- here represents the "meta" key.) This runs
enmime as a shell command, with the "M-1"
prefix keeping the shell's output in the current buffer (the email
message I'm currently writing). I then have to (manually) move the
two MIME headers up above the vm line:
--text follows this line--
since enmime sends its output to STDOUT and
of course has no idea about my email headers; that's not really a big
deal for me. I then type any text I want in the appropriate MIME
section, before the attachments.
demime is even easier:
| demime
Note that that is vm's pipe key (to pipe the email message buffer
contents into a shell command) and not [x]emacs's
M-|, which would operate on whatever region was currently
active (and give an error if none were active).
Hopefully these two scripts would be usable by other mail programs
(MUAs) which can't handle MIME natively but can at least run external
commands (and which live on systems where perl can be
installed).
NEW! (As of Wed Apr 11 17:22:01 CDT 2001)
If you use ssh, or a variant
such as OpenSSH, you can now
use an ssh-style syntax to attach
a file from a remote system to your mail message:
enmime me@example.com:remote_file.txt
.dvi produced by latex and
displaying all the hyphenations employed. If you see a bad one, you
can fix it with the \hyphenation command in LaTeX.
(Depends almost entirely on dvi2tty.)
.bib files for LaTeX. The first
three are fairly small and self-explanatory. find_bib_dups.pl
goes through a set of .bib files and check to see if any
entries have duplicate labels; organize_bib.pl takes the
entries in each supplied .bib file and lets you "dispose" of
it (append it to another .bib file or what have you); and
sort_bib.pl sorts the entries in each .bib
file by label (ASCII sort order).
search_bib.pl is a much uglier beast. You give
a search criterion (a string evaled as perl
code), and all of the entries for which the search criterion is true
are retrieved (the presentation can be tweaked a bit with command-line
options). Remember that eval STRING in perl
can be dangerous for a variety of reasons, so be careful what you tell
it (and WHO you let tell it!) to do.
I am told that the RefTex package for [x]emacs does this and much
more, and I am sure it does it much much better. (As you have probably
figured out by now I am much more likely to write a bad perl
program than do a simple web search when I need something.)
Most people I have seen using such a setup have a short
thesis.tex file which
contains the title page, dedication, acknowledgments, abstract and other
preliminary material, and then \inputs the various chapters
(each of which is kept in a separate file, such as
chapter_name.tex). Suppose you wanted to print just one (or
a few) chapters to show your advisor or committee members or people sitting
next to you on the subway; you could take your complete thesis file and
manually print the selected pages from it, but that could be tedious, or
perhaps you'd like a self-contained file that you can email someone.
You could of course manually delete (or comment out) everything in
thesis.tex but the chapter(s) you want, but that could be
dangerous ("I thought I had a backup!"), or at best tedious again... different
committee members might want different chapters, you forget to comment out
the thirty-page appendix, you used up all the printer paper again,
everybody's yelling at you.
Show_chapters takes the name of your master
.tex file, such as thesis.tex, and a list of
chapters which you can refer to by filename (the name given in the
\input statement), chapter number, or appendix letter.
Then it produces another LaTeX file containing only the title page
(plus the preamble material, so if you define e.g. math macros
or other commands here, they should be preserved), the table of contents
and figure and table lists, and the specified chapters. The -a
option lets you include the abstract if any. (One could use
\include instead of \input to get LaTeX to
do most of this for you automatically; but in that case, all of the topmatter
(dedication, acknowledgments etc.) will always be included.) When you run
latex and bibtex on this file, you'll also
get the bibiliographic references specified in those chapters; this
assumes however that your \bibliographystyle command appears
either in the preamble, or else near the \bibliography command
in the references section. Page numbering will be relative to the
new document, but the chapters themselves (and thus the sections,
figures, equations etc.) will be numbered as in the original (complete)
thesis. You can list the chapters in any order at the command line, but
they will be reordered as they appear in the original
.tex file.
One obvious problem: if you have a reference to a chapter that you're not including in the reduced document (or to a section, figure, equation etc. in such a chapter) then of course the reference will be broken (LaTeX inserts the text "??"). But if these are occasional, they can pretty much be ignored; and if you have a lot of them, then the chapters themselves are probably interdependent enough to make it worth printing them both.
easchithesis.cls, and was most recently maintained by
Dr. Martin Pergler when he was still in the Department of Mathematics
here. The other is maintained by members of the Department of
Astronomy, originally forked from version 1.5 of
easychithesis.cls; this version is currently called
ccw_chithesis.cls and is as of this
writing maintained by
Craig Wiegert.
I used the former class file, not being aware of the latter until
shortly before my defense. One comment line (shared by both versions)
states that the classes have "No support for multi-volume theses." I
tried to fix that (even though my own thesis was single-volume), and
added a couple of other options (one to allow roman page numbers to
all appear centered at the bottom of the page, as in earlier versions
of easychithesis, although this is currently disallowed by the
Dissertation Office; and another to add the word "Chapter" before the
first chapter in the table of contents as suggested but not required
by the Dissertation Office). I also stole the useful-looking
\makecopyright function from ccw_chithesis.cls,
and allowed for the degree-granting unit to be a \committee{}
instead of a \department{}.
This should definitely be regarded as an UNAUTHORIZED version of the
class file(s) at this point. Although I hope that some of what I did
here might be incorporable into the official version(s) at some point,
I have unfortunately not yet been able to contact the current
maintainers of ccw_chithesis.cls, and so
easychithesismv.cls should be considered entirely "use at
your own risk".
.bib files, rarely of use to the person making the
request. It seemed silly for me to translate the .bib
entries by hand each time, sillier still to keep a separate file with
ASCII versions of the relevant entries. Finally I got tired of
creating a blank LaTeX file each time with just a list of my citations
in it, and then cutting and pasting the (formatted) result into my
email response. This code basically automates what I used to do by
hand; the drawback is that it relies almost entirely on dvi2tty. It's also quite
specific to my own setup, unfortunately, although I hope to improve
that sometime soon.
Basically the problem is that when writing a paper in LaTeX, one likes to take advantage of all LaTeX's features that make such writing a joy rather than a chore. Automatic bibliography inclusion and formatting via BibTeX. Automatic resetting of figure axis labels and legends with psfrag. Automatic numbering of everything. And what's this, the journal will accept LaTeX files as well as MS Word? What could be better?
Then you read the requirements. It must be a "self-contained"
.tex file; this means no BibTeX (or else
\input{myfile.bbl}, and hope that the journal is willing
to deal with that when you upload the two files; or else basically doing
that by hand every time you make changes to your paper); it means no
psfrag (because they want "self-contained" figures uploaded separately
from the text of the manuscript); and it means in some cases that they
want the figure files to be physically named things like
fig1.eps, fig2.eps etc. (so much for automatic
numbering; or else you have to hope you don't have to reorder anything
once you've gone and assigned your figures those names).
What I was trying to do with this script was to automate most of
these steps. The goal is to be able to write a paper as one normally
would without regard to the journal's requirements mentioned above.
The script then takes your "input" .tex file and
"converts" it: the figures are each expanded into individual files,
named in the order they appear in your document; the .bbl
file is physically included into the output .tex file;
and comments are stripped (just in case :)). Lots of bad
assumptions, lots of hard-coded numbers; I don't honestly expect this
to be usable at the moment to anyone else, but maybe if someone did
try it, and told me what they were trying to do with it, and how it
failed spectacularly but unsurprisingly, then I might be able to
address one of those hidden assumptions. Trivial example: sometimes a
journal will ask for a list of figure captions at the end of the
manuscript; that's currently commented out (IEEE TMI wanted it but JMP
didn't), but should by rights be a user option.
Good luck.
Last modified: Wed May 31 17:16:32 CDT 2006