Some TeX Developments

Around two years ago, I wrote a short post comparing MiKTeX and TeX Live for Windows-based TeX users. Looking at my log files, this topic is perhaps the most common search term that brings people here. As such, I think it’s time to revisit the question and bring what I said before up to date.

On Windows, there are two actively-developed TeX systems with similar coverage: MiKTeX and TeX Live. Before I look at the comparison, a reminder that they are not the only choices. W32TeX is popular in the far east, and as well as being a TeX system in its own right is the source of the Windows binaries for TeX Live. There are also the commercial BaKoMa and VTeX systems (although whether anyone can get hold of the supplier of the latter is another question). However, for most users it comes down to a choice between the ‘big two’.

The good news is that there is a lot of similarity between the two systems, so for most users both systems are equally usable. However, there are differences and depending on what you need these might be important.

• The standard settings install everything for TeX Live, but only a minimal set of packages for MiKTeX. MiKTeX will then install extra packages ‘on the fly’, while TeX Live does not (there is a package to do that in TeX Live, but it’s aimed at Linux). Install-on-the-fly is useful if space is limited, but is more problematic on server set ups. So this is very much a feature who’s usefulness depends on your circumstances. Of course, there is nothing to stop you using MiKTeX and installing everything.
• The xindy program is only available in TeX Live. For those of you not familiar with it, xindy is an index-processor, and is much more capable of dealing with multi-lingual situations than MakeIndex. If you need xindy, TeX Live really is the way to go.
• MiKTeX is very much a Windows tool set, while TeX Live comes from a Unix background. This shows up from time to time in the way TeX Live is administered, and the fact that the TeX Live GUI is written based on Perl rather than as a ‘native’ Windows application.
• As TeX Live is the basis of MacTeX, and is the TeX system for Unix, if you work cross-platform and want an identical system on all of your machines, then TeX Live is the way to go.

WinEdt is a popular (La)TeX editor on Windows. A new major release, version 6, has just appeared on the WinEdt homepage. The interface has received a lot of attention, with new icons and menu arrangements. One thing that a lot of people have been hoping for is UTF-8 support, but the release notes say

Avoid sending major feature requests: they will have to wait for version 6.1 (unicode, folding and all)!

So for the moment people who need UTF-8 will have to look elsewhere. Another point to note for users of version 5.5 is that this is not a free upgrade (WinEdt is shareware).

As I posted earlier, the upcoming releases of both MiKTeX and TeX Live have very similar sets of features on Windows. I’ve just stumbled upon something that points up the slight differences that exist, even though this one is a bit complicated.

To detect what system is being used, for things like shell escape tricks, there is a LaTeX package called ifplatform. However, this only works on Windows if MiKTeX is being used. The reason is that while TeX Live aims to be as similar as possible across platforms, MiKTeX can adopt a different approach and stick to Windows conventions. Most of the time, this is transparent but it shows up if you use the -shell-escape option for either system and try to do some testing. Inside ifplatform, you’ll find the lines:

\edef\ip@sig{write18-test-\the\year\the\month\the\day\the\time}
\edef\ip@win{'\ip@sig'}
\immediate\write18{echo \ip@win >"\ip@file"}

The idea is that the text written to the temporary file will be different on Windows to on a Unix-like system. MiKTeX will retain the single quotes around the test data:

'write18-test-20098231074'

whereas Unix-like systems will not:

write18-test-20098231074

But try using ifplatform with TeX Live on Windows and the test fails. First, no test file gets written at all: a bit of hacking leads to the change of the write line to

\immediate\write18{echo \ip@win > \ip@file}

and then at least the first step works. However, the test file now looks like a Unix one (with no quote marks), and ifplatform gets things wrong. So for the moment the only thing to do is create a stub package file and use it, something like:

\ProvidesPackage{ifplatform}[2007/11/18 v0.2  Testing for the operating system]
\newif\ifshellescape\shellescapetrue
\newif\ifwindows\windowstrue
\newif\ifmacosx
\newif\iflinux

I’ve reported the problem to Will Robertson, and hopefully a solution which really tests the OS rather than the TeX system can be found. However, it is a reminder that even with very general feature sets, the two major TeX distributions still act differently in some respects when used on Windows.

As many people will know, the CTAN team have come up with the idea of having TDS-ready zip files for packages. The idea is that you can just download the zip into your local TeX directory, unzip it and run texhash, with no TeX-based unpacking or document compilation.

That’s all fine when it works, but I’ve recently had a bit of trouble making zips at my end. My favoured tool for doing that has tended to be 7-Zip. However, it was pointed out to me last week that the resulting zip files are not quite right. On Unix systems, the command unzip -xa will convert line endings to the system convention (LF only), even if they come from Windows (LF-CR endings). However, this requires that the zip identifies text files, and 7-Zip marks everything as binary!

I did a bit of hunting around, and found Info-ZIP, where after a bit of hunting about you can find zip and unzip binaries for Windows. These give me Unix-like capabilities on Windows, so I can make the appropriate files, alter line endings on zipping/unzipping and check the results.

That led me to take another look at the batch file I use each time I release something to CTAN: doing it by hand is an unreliable business! I’ve reworked it quite a bit, to generalise everything and also add a few tweaks. For anyone interested, the file is available here. It’s called make, so that you get Unix-like abilities on Windows. The file has to be customised for each package I write, but most of this version is generalised, and can be altered using a few settings.

set AUXFILES=aux cmds dvi glo gls hd idx ilg ind ist log los out tmp toc
set CLEAN=bib bst cls eps gz ins cfg pdf sty tex txt zip
set DOCEXTRA=\AtBeginDocument{\OnlyDescription}
set INDEXFILE=gglo
set PACKAGE=achemso
set PDF=%PACKAGE%
set TDSROOT=latex\%PACKAGE%
set TEX=achemso-demo
set TXT=README
set UNPACK=%PACKAGE%.dtx

Anyone at all familiar with batch files will see that this is a block of environmental variables: in this case, these are the settings for my achemso package. Most are pretty obvious settings, but in case anyone wants to use the file for their own purposes:

• AUXFILES File types to delete after every run: throw away files.
• CLEAN File types deleted only if make clean is run: useful stuff.
• DOCEXTRA Inserted when creating documentation, can be anything. I don’t typeset the code for my packages in the release documents, hence the \OnlyDescription setting.
• INDEXFILE This is always gglo for documents using the ltxdoc class, but is l3doc if using the LaTeX3 class l3doc.
• PACKAGE Pretty obvious, the bundle name!
• PDF The names of PDF files to add to the documentation part of a TDS zip. By having this as a setting, special effects (demo documents, for example) are possible.
• TDSROOT. Almost always as given for a LaTeX package.
• TEX A list of .tex files to copy into the TDS archive: to avoid any testing files, not all .tex files are copied.
• TXT The names of text files to copy to the documentation directory
• UNPACK The file(s) to run to unpack the package. I use .dtx files that are self-extracting, but the traditional method is to have a separate .ins file.

If the batch file proves useful to enough people, I might write some proper documentation and do a bit more generalisation.

With all of that in place, I can hopefully keep Unix-based LaTeX users happy without too much work!