Musings

Back in the early '90s, exchanging TeX files with figures was a dodgy proposition. There was little interoperability between different implementations, and bandwidth considerations made shipping around (what, at the time, seemed rather large) figure files, which might not even work for the recipient, seem a less-than-attractive proposition.

Eventually, we settled on EPS figures, included with widely-supported macro packages, like epsf.tex. (Heck, someone even did a Macintosh port for Textures!)

With LaTeX2e, graphicx.sty became the standard package for including graphics, with even better cross-platform support. (Don’t even dare suggest using epsf.sty, lest Dave Carlisle personally track you down and inform you of the error of your ways [I wish I could find that mailing list exchange from the mid '90s; it was priceless.].)

Anyway, this beautiful equilibrium was disrupted when MacOSX, TexShop and, pdfTeX came on the scene. PDF is the native-windowing environment under MacOSX, so pdfTeX was a pretty natural choice. Rather than the convoluted TeX→DVI→Postscript→PDF, you could go straight from TeX→PDF, with pdfTeX.

But pdfTeX works only with PDF figures, not EPS. At the very least, you’d need both a figure.eps and a figure.pdf file for interoperability. GhostScript will convert .eps to .pdf. In fact, just dropping such a figure file onto TexShop will do the conversion for you. So that’s not a problem.

But what about including the figure in your TeX file? It turns out that graphicx handles both file formats with aplomb. All you have to do is remember to omit the file extension when inputting the figure:

\includegraphics[width=36ex]{foo}

and foo.pdf will be used with pdfLaTeX, while foo.eps will be used with LaTeX/dvips/GhostScript.

But what about Plain (pdf)TeX? For the longest time, I couldn’t figure out a solution. But then, quite by accident, I discovered that

\epsfxsize=36ex\epsfbox{foo.eps}

will work just fine with pdfTeX, provided you have both the .eps and .pdf figure files lying around. Apparently, epsf.tex will read the .eps file to get the bounding-box information, but then pdfTeX will auto-magically use the .pdf file to produce the actual figure.

Update (8/28/2004): Whoops! That’s not what it’s doing at all. Looks like a little more work needs to be done to get intelligent figure inclusion in Plain (pdf)TeX.

Update (8/30/2004): Well, here’s one quasi-solution for Plain TeX: use graphicx.tex, a Plain TeX wrapper around Dave Carlisle’s LaTeX package. Put a

\include graphicx

at the top of your TeX file and include the figures as above.

Unfortunately, unlike in the LaTeX version, the driver is hard-coded and defaults to dvips. So what you need to do is

1. Copy the file

   /usr/local/teTeX/share/texmf.tetex/tex/plain/graphics/graphicx.tex

   to either

   /usr/local/teTeX/share/texmf.local/tex/plain/graphics/

   or to ~/Library/texmf/tex/plain/graphics/ .
2. Edit the file to change the line

   \def\Gin@driver{dvips.def}

   to read

   \def\Gin@driver{pdftex.def}

   instead.
3. Run

   sudo texhash

   to make sure everything’s up-to-date.

Now the driver is hard-coded to pdftex and will use the .pdf figures. If your friend uses TeX/dvips, his TeX setup will pick up the .eps figures as before.

It’s awkward to have to hard-code this choice. Maybe some TeX maven can figure out a way of auto-detecting which driver to use. After all, LaTeX manages to do it…

Update (8/31/2004): Nathan Goldschmidt is our hero for the day! With the (improved!) graphicx.tex file, everything works automagically:

\input miniltx

\ifx\pdfoutput\undefined
  \def\Gin@driver{dvips.def} % we are not running PDFTeX
\else
  \def\Gin@driver{pdftex.def} % we are running PDFTeX
\fi
 
\input graphicx.sty
\resetatcatcode

Update (10/4/2004): A conversation with Mark Srednicki made me realize that the advantages of using pdftex instead of tex/dvips/ghostscript were not drop-dead obvious to everyone. So here is a partial list:

1. It’s faster, and generates fewer junk (.dvi, .ps) files along the way.
2. Trouble-free PDF output, which won’t cause FastLane to hork a loogie.
3. pdfsync support. With this (La)TeX macropackage, clicking on a spot in the PDF preview bring you to the corresponding point in the TeX source file. Amazingly useful while editing.

4. HyperTeX support. The hyperref macropackage creates clickable hyperlinks in your document. It automatically generates internal ones — to sections, numbered equations, references, etc. — and, with the help of things like my bibtex style file and modified article class one gets external links, to papers on the archives and mailto: links for author email address(es). Or you can add your own, with the \href{}{} macro.

   Unfortunately, all these links are lost when passed through tex/dvips/ghostscript. You need to use pdftex.

5. For really high-quality typography, you can enable margin kerning.

[Updated (10/1/2004) for ecto 2.0b35 and later.]

What with working on our NSF proposal (Note to self: when you volunteer to write the LaTeX templates for the proposal, be prepared for the obvious consequences.) and preparing for the start of classes, I’ve barely had the chance to bathe (just kidding), let alone blog.

But, with the proposal more-or-less done, and classes underway, I did take an hour off to engage in a little geekery. As mentioned earlier, I now have MathML “support ” working in ecto 2.0. Specifically, I have three plugins for ecto, which implement the

• itex to MathML
• itex to MathML with parbreaks
• Markdown with itex to MathML

text filters I have installed on this blog.

“Support” is in quotation marks. When you compose a post, using one of these text filters, it will be processed into XHTML+MathML and the previewer will display it, just as Safari would see it, were you to post it to your blog. That is, the equations will look like gibberish.

Nothing much to do about that, until Dave Hyatt gets on the case. Still, even though the MathML doesn’t render, you can still usually tell that you didn’t have major errors in your LaTeX equations, from the fact that they were successfully converted to MathML.

I may still try to hack Validator support into these text filters. But, on reflection, that just seems backwards. Much better to convince Adriaan to integrate Validator support into ecto 3.0.

If you have ecto 2.0 (beta 35 or later), and want to play around with the plugins, installation is easy.

1. Put the plugins in ~/Library/Application Support/ecto/plugins/ .
2. Put the itex2MML binary (included) either there, or in /usr/local/bin/ (the plugins will find it in either location).
3. Select a text filter for your post (a subset of the ones installed on your blog).
4. Enjoy.

Gee. It’s been a while since I posted something. Truth be told, I’ve been insanely busy, and the madness won’t let up for at least a week or two.

But I did want to to point out that this is being posted using a beta version of Ecto 2.0.

“Ho hum,” you say. But that would be wrong. Ecto 2.0, among its other, doubtless extremely useful features, has local text filters. Say you have a bunch of text filters installed on your blog. You can choose your post to be to be filtered with one of those filters when it is published. But, when previewed in Ecto, this had no particular effect (except for the standard “convert linebreaks” filter). All you would see was the unfiltered text.

But now you can create plugins for Ecto which process your text before it is previewed. The plugin applied your text is selected based on your choice of MT text filter. So, obviously, I could create a plugin which runs my text through itex2MML before displaying it. That would be really nifty (even niftier if WebCore supported MathML).

But even craftier things are now possible. How about a plugin which runs your post through the text filter of your choice and then runs the result through the validator? Instant client-side validation, in addition to text filtering!

Someone stop me before I drop what I’m doing and pull an all-nighter coding Ecto plugins!

For the past week, I’ve been wandering around, morosely muttering under my breath about the “traitors” in the White House, who would sell out our national security for political advantage. Thankfully, the incomparable Medium Lobster has come through with an explanation to restore my confidence in our fearless leaders.

In this age of partisan attacks and free-for-all political smearing, the Medium Lobster has seen one low blow follow another after another. Is there nothing vicious Democratic attack-dogs will not politicize? Alas, the answer to that obviously rhetorical question is a heartsticken “no.” Because for the past week, certain individuals have repeatedly attacked the White House for doing its diligent duty in outing a Pakistani double agent working to expose an al Qaeda cell. Sadly, the reasoning being displayed by those criticizing the administration reveals not only a perversely partisan mind, but a lack of comprehension regarding the role of modern intelligence.

There are times in warfare when raw force, for reasons of stretegy or of simple human decency, is not an acceptable means of hastening the end of a conflict — but a show of force is. Hence the dropping of the atomic bombs in World War Two, the “shock and awe” tactic in the recent Iraq War, and so on. Rather than completely annihilating the enemy, the “show of force” demonstrates to the enemy that one has the ability to completely annihilate them, and so instills a terrifying dread of force that it compels the enemy to give up the fight.

Intelligence, of course, is just another instrument of war. And intelligence, like force, can only be used to a certain extent in any given situation. But a show of intelligence will instill an absolute dread of one’s investigatory powers in the terrorist mind. So while Mohammed Naeem Noor Khan could only accomplish so much as an actual source of hard intelligence - perhaps breaking up a terrorist cell here, exposing a plot there, assisting in the capture of bin Laden lieutenants there - as a show of intelligence, exposed and outed as an intelligence source, Khan is far more valuable - terrorizing the terrorists themselves. The Medium Lobster would not be surprised if Osama bin Laden himself were trembling in some dark cave, marveling at the well-oiled efficiency of the American intelligence apparatus, wondering how many other theoretical Khans were out there waiting to inform on him.

In the future, the Medium Lobster looks forward to more intelligence initiatives against the terrorists, from the revealing of more top sources in the hunt for bin Laden to the spilling of the nuclear launch codes. America has the knowledge and the capacity to defeat its worst enemies; now it has to prove that to those enemies by revealing that knowledge.

Thanks to this brilliant arthropod, I can spend my remaining days in the Bay Area with my head held high.

In other news: Kerry Campaign Condensed.

I’m currently on vacation (hence the dearth of postings recently), but I do have a request.

If you are using my itexToMML plugin (for either MovableType or WordPress), please leave a comment to this post. If you prefer, send me an email instead. Either way, I’d really like to hear from users about how they are using the plugin, and their thoughts, more generally, on putting math on the web.

Joshua Kaufman wins a prize for figuring out how to sneak ill-formed content (in this case, an unescaped ampersand in the comment-author field) past my comment-validation/forced preview setup.

I’ve made the appropriate revisions, but that was very clever, Josh.