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.

Spaces in file names are a constant issue for LaTeX users. As many people will know, TeX is not really very happy with spaces, as they are used to delimit the end of input in a lot of low-level macros. This shows up particularly in two areas: graphics and shell escape. For graphics, the excellent grffile package will deal with many of the issues. When using shell escape, the issue is usually that \jobname may be slightly odd. For TeX Live users, that is not so much of a problem as the name is automatically quoted to protect the space. However, MiKTeX does things a bit differently, and uses a star in place of a space. So you end up with

\edef\example{\jobname}
\show\example
> \example=macro:
->test*file.
l.2 \show\example

which is not exactly helpful. However, it is possible to deal with this, as recently mentioned on TeX.SX. As * cannot normally appear in file names, and \jobname makes all characters have category code 12, a simple approach is to do a quick replacement

\edef\Jobname{\jobname}
\catcode`\*=\active
\def*{ }
\edef\Jobname{"\scantokens\expandafter{\Jobname\noexpand}"}
\catcode`\*=12 %
\show\Jobname

If you want to deal with both TeX Live and MiKTeX, you’d of course need first to test which system is in use (for example using \pdftexbanner).

The LaTeX3 Project have recently updated the organisation of the various LaTeX3-based packages on CTAN. This means that the older expl3 and xpackages need to be replaced by l3kernel and l3packages. Unfortunately, this seems to confuse MiKTeX, which does not pick up the need to install the new material. So MiKTeX users will need to do this by hand in the MiKTeX Package Manager. This should be a passing problem, but does seem to be causing some confusion for MiKTeX users.

Security in computer programs is always an issue, with the balance between ease of use and security never being a simple black and white line. There’s a very interesting paper, being presented at an upcoming conference, about TeX security issues. This is particularly significant to MiKTeX users, as it’s led to a change in how MiKTeX implements certain features.

One of the well-known security questions with TeX is whether to enable \write18, and as a result this is off by default in TeX Live and MiKTeX. Another area that is of obvious concern is the \openout primitive, which allows writing a new file and could therefore be used for undesirable purposes. Of course, this functionality is also important: writing to files is how LaTeX manages a whole range of automated cross-referencing. So there is a balance to be struck: we need \openout, but not at any cost.

The TeX Live team have taken the attitude that \openout should be able to write within the current directory structure but not outside of it. This can be seen with a couple of very similar plain TeX test files. If you try

\newwrite\mywrite
\immediate\openout\mywrite test/test.xxx
\bye

then everything will be fine and the test file will be created. On the other hand

\newwrite\mywrite
\immediate\openout\mywrite ../test.xxx
\bye

will raise an error. The behaviour with MiKTeX was to allow both (and also absolute paths, etc.). That has now been altered, so that MiKTeX behaves in the same way as TeX Live (at least, that’s what it looks like in my tests).

Reading the MiKTeX lists, the new behaviour is causing issues because LaTeX’s \include relies on \openout. Quite a lot of MiKTeX users have been doing things like:

\include{C:/Users/<user>/My Documents/Chapters/chapter1.tex}

or

\include{../Chapters/chapter1.tex}

which used to work and now does not. There is a setting which enables the old behaviour, but it’s not really to be recommended, I think. So users will have to rearrange their input a bit to reflect the new more secure approach.

There are some other interesting points in the paper on TeX security. One is that making a truly secure LaTeX implementation (to use as a web service) is basically impossible. The MathTran site gets mentioned as the most secure TeX web service: it uses a specially hardened version of plain TeX, with no access to things like \csname, \catcode and so on to make it secure. For LaTeX, that is probably not possible (at least with LaTeX2e). Worth reading, but for those of us who just use TeX on our own computers not quite so immediately relevant.

I was talking to someone at work recently, and the topic of whether to choose MiKTeX or TeX Live on Windows came up. With MiKTeX 2.8 released and TeX Live 2009 due out any day, I thought I’d make a few comments.

First, both systems are very capable, so there is not really a “wrong” decision. However, when installing you do have to pick one. In the past, MiKTeX was the best choice for Windows by a distance, but recent work on TeX Live has altered this. So I’d say there are some factors to balance against each other.

• If you work on Windows and on Unix, then TeX Live is the system to favour. It preforms essentially in the same way across platforms, whereas you’ll get some minor differences if you use MiKTeX on Windows and TeX Live on Unix.
• If you want to only install what you use, go for MiKTeX. TeX Live doesn’t have anything to match the auto-installation system in MiKTeX.
• On the other hand, if your happiest installing everything in one go, go for TeX Live. It does this by default, and includes any new packages when you do an update. For MiKTeX, a full installation is something you have to do deliberately.

As you’ll see, there is not much in it! I’m mainly using TeX Live, but still have MiKTeX around as well.

One issue a lot of people find confusing with (La)TeX is the rules about which types of graphic files work with which engines. EPS files are fine when going via the DVI route, but do not work with direct PDF creation. The solution is to turn the EPS files in PDFs, and the problem goes away. However, there is then the question of how to do the conversion.

For most documents, having to convert every file by hand is not a sensible choice. The next nearest thing is the epstopdf package, which will do the same thing but from within a LaTeX run. However, it needs \write18 enabled, and this is not always desirable. More importantly, a lot of people who struggle with the graphics problem do not know how to turn on \write18 anyway. A good way around has been added to the latest version of TeX Live, which is currently in the final testing stages. TeX Live 2009 has some restricted \write18 functions enabled as standard, and also has a version of epstopdf “built in”. The result is that EPS files are automatically converted to PDF files, in a transparent manner. Of course, this only happens if the PDF does not also exist! At the moment, this feature is not in MiKTeX 2.8, so it is one reason to favour TeX Live 2009 even on Windows.

There are places where epstopdf will not help: for example, when using psfrag or pstricks. There, the best solution will either be auto-pst-pdf or pstool. Both are written by Will Robertson, and both need \write18 enabled to work. pstool is more efficient (it only re-creates graphics as needed), but for some cases on auto-pst-pdt will work. Will has documented both packages very well, so the best way to learn about them is to have a read of the documentation.

A quick note to say that MiKTeX 2.8 was released on Tuesday. As I’ve already posted, the two points to note in the new version are the inclusion of TeXworks and better support for multi-user systems. There seem to be one or two teething issues, but I’m sure they’ll soon be solved.

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.

Both MiKTeX and TeX Live have new versions in the offing. I’ve been testing out both MiKTeX 2.8 and TeX Live 2009, to keep up to date with what is happening. In the past, I’ve tended to stick with MiKTeX as it is designed for Windows, and so can make some platform-specific decisions and be more focussed. However, the TeX Live team have done a lot of work to make TeX Live usable across platforms, and there are advantages to that approach.

Looking through the feature lists, a lot of the new features are common to the two systems, for example:

• TeXworks installed as a distribution-maintained editor.
• XeTeX version 0.9995 (which includes the new primitives that the LaTeX3 team asked for).
• Some \write18 functions enabled without turning on full \write18 support: this is used to allow “safe” functions.

There are, of course, also differences. For example, only TeX Live includes LuaTeX at present. I also notice that MiKTeX 2.8 is adding the full path of files to the log, whereas in the past you got the relative path. I’m not so sure this is a good idea: it makes things rather wordy, and also the log will vary between systems: not so great. On the other hand, MiKTeX 2.8 does provide user-specific texmf directories. For multi-user systems, this is a real bonus: you can use the auto-install system without needing to be the Administrator.

As I said, I’ve tended to use MiKTeX to date as it’s been the best “fit” on Windows. The latest version of TeX Live makes this a pretty tight call, I think. If you are happy installing a full TeX system (which I do), then there is very little in it. MiKTeX still has the edge for small installations, as the auto-install system really pays off there.

Jonathan Kew has produced new binaries for TeXworks for both both Windows and MacOS X. The ZIP file now contains everything you need to download in one place, which makes installation that bit easier.

On a somewhat related matter, I see that MiKTeX 2.8 is going to include TeXworks, including setting up file associations (.tex and .sty). As TeX Live 2009 is also coming with TeXworks, getting hold of the programme should become very easy for end users. This can only be a good thing.