XeTeX users are likely to load system fonts, and I’d hope be using UTF-8 input. That makes it hard to auto-detect what they are doing, but should make life easier for them to get things right. A lot of more comprehensive fonts include Greek letters in the main font, so getting the μ right is simple:

\sisetup{
  mathsmu = \text{μ},
  textmu  = μ
}

or for people testing version 2 of siunitx:

\sisetup{
  maths-micro = \text{μ},
  text-micro  = μ
}

There may be a bit of testing required: this will not work if, for example, you are using the Latin Modern font.

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.

I’ve recently talked about adding new primitives to XeTeX, and you’ll see that \pdfmatch was not on the list for adding to XeTeX. The reason is that a XeTeX implementation would have to be slightly different from pdfTeX, as it is natively UTF-8, but also would be different to LuaTeX, as it would still be a TeX primitive and not a Lua function. So here “the prize wasn’t worth the winning”, in my opinion. As it is,  using \pdfmatch is not widespread, and the idea of having three different regex methods inside TeX didn’t seem like a great idea!

Talking of regex implementations, I’ve been reading Programming in Lua, and also working with TeXworks to try to get syntax highlighting the way I like it. Both systems are slightly different, and it seems both are different from the Perl implementation. It seems that every time you want to use a regex system you have to read the manual to see which things are different from every other implementation!

• \ifincsname
• \ifpdfprimitive
• \pdfprimitive
• \pdfshellescape
• \pdfstrcmp

At the same time, it would be useful to include the “extended” version of \vadjust which pdfTeX makes available. This is something that has been asked about before, and as with the rest of the changes the main issue is not the idea of doing it but the time for actual implementation.

The real need to have \pdfstrcmp available for LaTeX3 work means that some effort has actually gone into this. I’ve got no experience with either Pascal or the WEB format, but I’ve managed but dint of determination to get something passable to Jonathan Kew. There will need to be some adjustments, as XeTeX works with UTF-8 internally, which pdfTeX does not do. However, I’m hopeful that we will see new primitives in XeTeX soon.

Quite how the primitives will be named is still to be decided. The existing \pdf... naming does not really make sense with these non-PDF related functions. So they could end up as  \XeTeX... or may just be given generic names. I’m leaving that to Jonathan!

XeTeX is based on ε-TeX, which means it has a number of primitives which were not present in TeX82, but are present in ε-TeX itself or in pdfTeX (which also includes the ε-TeX primitives). However, ε-TeX was finalised over ten years ago, and since then the pdfTeX team have added a number of new primitives, many related directly to PDF output. At the same time, XeTeX includes its own new or extended primitive functions, in this case focussed on UTF input. For the most part this does not concern people as things work fine.

Recently, there has been some testing of the current LaTeX3 code with XeTeX (and older versions of pdfTeX, which don’t have all of the newer primitives). LaTeX3 requires the ε-TeX extensions, which are as I said available with any modern TeX engine. However, when it’s available LaTeX3 also uses the \pdstrcmp primitive: this is only present in newer versions of pdfTeX. For those people not familiar with \pdstrcmp, it allows you to do string comparisons of text (not token comparisons), and in an expandable manner.  This is very useful, and much better than doing things without it; with no \pdfstrcmp, comparisons are not expandable. It became clear that there is a danger of some things working when using newer versions of pdfTeX, but failing with older ones or with XeTeX. Older versions of pdfTeX is one thing (the advice can simply be “sorry, you’ll have to update your pdfTeX”), but failing with XeTeX is simply no acceptable. After a bit of discussion, the best solution seemed to be to talk to Jonathan Kew about getting a very small number of “new” pdfTeX primitives into XeTeX.

At the moment, things are still under discussion, but the list of additional primitives is going to be small (somewhere between 2 and 5 seems likely). I think it’s giving nothing away to say that \pdfstrcmp is one that really is needed (although the name might be an issue!). Another likely candidate is \ifincsname, which looks handy and also not too complex to implement. There are a few other suggestions, but I’m not sure just yet what will be really needed, as opposed to nice to have. What is clear is that this is a one-off request. Once these small gaps are filled, LaTeX3 will not be using other primitives for general functions. I’m not sure how long it will take to finalise things, both for the team to agree on what is needed and for Jonathan Kew to do the hard work, but I’d imagine weeks not longer.

The snag can be tracked down (thanks to Morten Høgholm) to a minimal case:

\message{\ifcat\par\relax T\else F\fi}

If you try this in TeX or pdfTeX, you get T in the log (as The TeXbook says you should). With XeTeX, you get F. Whether this is a bug or a feature, I don’t know. I’m sure Jonathan Kew will elaborate, but it reminds me of the need to test using different set ups. You can imagine some very odd errors appearing with this type of thing!

\let\everypar\undefined
% \everypar{Some stuff} % Gives an error
\pdfprimitive\everypar{Some stuff}

will, for example, add material to \everypar despite the redefinition.

In LuaTeX, the idea of adding an engine-specific prefix has been abandoned. The example above shows one reason why: \pdfprimitive makes more sense with the name \primitive (which is what LuaTeX calls it). The problem with this is that name clashes are marginally more likely without a prefix (for example, \expanded is used in ConTeXt as a macro, but this is planned as a primitive for pdfTeX 1.50).

On the other hand, LuaTeX is a fundamental break with previous engines, as the internal changes mean that it may give different line breaks and so on to earlier systems. Thus the argument for new, logical, primitive names is that moving to LuaTeX is not the same as moving from TeX to pdfTeX or pdfTeX to XeTeX. There will be changes, and the user (or package developer) will need to think about them before diving in.

Overall, I think the LuaTeX idea is the best in the long term. Primitives which have well specified names help everyone, and some times change is necessary. I’ll be interest to see if the \directlua primitive for actually using Lua ends up with a shorter name (just \lua, anyone?).

With the correct packages and class loaded, you can do many things in LaTeX.  However, you really shouldn’t need to load specific support for hyperlinks, T1 encoding, basic font changing, creating new float types and so on in 2009 (let alone 2010, 2011, etc.).  The efforts of the LaTeX3 team have to date focussed on programming and to a lesser extent document design.  How things will work at the user level is much less clear.

I’d suggest that a real focus on getting something for users would be the best way forward.  This might mean less improvement internally, but I’d think that a LaTeX kernel which could do everything in The LaTeX Companion would be pretty successful, even with few changes “under the hood”. This would mainly be a re-coding excercise from existing packages, which in a way is similar to what I’ve tried to do with siunitx.  Much of the basics in siunitx are taken from other packages (at least in terms of user interface), but it brings several ideas together in one place.  The same idea could easily be applied to the kernel.  Of course, this might leave some of the clever ideas for LaTeX3 out of the code at this stage, but I’d hope would get momentum behind a more regularly updated system.

One particular area to think about is fonts.  With both XeTeX and LuaTeX able to handle system fonts directly, the basic LaTeX system seems very antiquated.  At present, LaTeX3 only requires e-TeX, not LuaTeX (in contrast to ConTeXt Mark IV).  Should the LaTeX team say something like:

For current testing purposes, only the e-TeX extensions are needed, but this is likely to change.  XeTeX or LuaTeX will be required to run the release version of LaTeX3 with full functionality.

I’d say yes, as I think that it’s time to move on from complex font installation and usage restrictions.  I’d also be very tempted to say that LaTeX3 will assume UTF-8 input unless otherwise specified (as both XeTeX and LuaTeX are native UTF-8 systems).

This type of approach will make LaTeX easier to use, and I’d hope to see it arrive!  After all, users are the TeX community.

The issue for me is the gaps between the two. XeTeX doesn’t have things like microtypography (try loading the microtype package and doing a XeLaTeX run), and it’s not clear to me how LuaTeX will work out with font handling. There’s also the DVI versus PDF issue: will we see a system where EPS, PNG, JPEG and PDF graphics can all be included without worrying about the engine in use? In many ways, I suppose these questions are more for the LuaTeX team to address: XeTeX has essentially delivered what it set out to do (a Unicode TeX which can use system fonts natively).