xparse: optional arguments (at the end)

For many years, the LaTeX team have been wondering about a subtle question: how do we deal with spaces before optional arguments. It’s easy enough if we know there are more mandatory arguments to look for:

\foo{first}  [optional]  {second}

should be treated in the same way as

\foo{first}[optional]{second}

However, when the optional argument comes last, it’s a bit more tricky. It’s easy enough to have

\foo{first}[optional]
\foo{first}  [optional]

both do the same thing, but there is one classic LaTeX2e case to worry about. When you load amsmath, you’ll find that

\begin{align}
   a  & b \\
  [c] & d \\
\end{align}

doesn’t treat [c] as the optional argument to \\: spaces are not skipped here. (This is pretty sensible for mathematics: it’s quite possible to have something in square brackets.)

To date, we’ve handled this by simply not allowing any spaces before optional arguments when they come ‘at the end’ (after any mandatory ones). However, that means it applies to all cases, which we’ve thought for some time was not ideal: most of the time, spaces here are likely fine.

For the next release of xparse, we’ve revisited this area and introduced a new ! modifier for optional arguments. Unmodified optional arguments will now allow spaces, with the ! modifier preventing this. Thus we can now describe \\ as having xparse set up

\DeclareDocumentCommand{\\}{!s !o}{<code>}

meaning no spaces are allowed, whilst most other commands will now allow spaces. This should affect very few end user documents, but does make for a better long-term approach.

LaTeX2e: UTF-8 as standard

Stability is a key idea when making changes to the LaTeX2e kernel: users need to know that they’ll always get the same output for the same (valid) input. At the same time, the world moves on and we need to respond to real-world use. To date, the LaTeX kernel has stuck to purely ‘classical’ 7-bit input support ‘out of the box’, meaning that with pdfTeX you need to load inputenc to properly use any extended characters. For English speakers that doesn’t really show up, but almost everyone else needs

\usepackage[<encoding>]{inputenc}

at least unless they are using XeTeX or LuaTeX. When there were many competing input encodings, having to load one specifically made more sense, but today UTF-8 is the standard, and (almost) all new documents should be using it.

For the next LaTeX2e release, the team are changing this position, and UTF-8 will be understood as default: https://github.com/latex3/latex2e/issues/24. For most users, this will be entirely transparent: they’ll already be using inputenc. Of course, there will be a few users who need to make adjustments, most obviously those who have relied on the default settings for the upper-half of the 8-bit range (they will need \usepackage[latin1]{inputenc}).

Testing is underway and a few areas are still being addressed. The aim is to make life easier for all LaTeX users: feedback is most welcome.

beamer developments

I’ve been looking after beamer for a few years, largely ‘by accident’ (this seems to happen quite a lot). Relatively recently, I moved the code from BitBucket to GitHub, largely because there’s a slow drift there for LaTeX projects. The advantage of that is the chance to pick up additional help.

Eagle-eyed readers will have noticed that over the last few months there have been a lot of beamer check-ins from Louis Stuart. He’s doing excellent work on tackling a lot of tricky beamer bugs, and I hope this will mean a better user experience. Of course, changing a complex product like beamer does have some risks, and so it’s also important to get the release set up working smoothly. To that end, I’ve migrated from some custom Makefile structures to using l3build (with some new features in the latter to help). That should mean a more regular release schedule.  It also means we can integrate testing into the coding: currently there is just the one test, but I’d welcome additions!

LaTeX2e kernel development moves to GitHub

The LaTeX team have two big jobs to do: maintaining LaTeX2e and working on LaTeX3 (currently as new packages on top of LaTeX2e). For quite a while now the LaTeX3 code has been available on GitHub as a mirror of the master repository. At the same time, the core LaTeX2e code was also available publicly using Subversion (SVN) via the team website. At least in the web view, the latter has always been a bit ‘Spartan’, both in appearance and in features (only the most recent revision could be seen).

Coupled to viewing the code for any project is tracking the issues. For LaTeX2e, the team have used GNATS for over twenty years. GNATS has served the team well, but like the web view is Subversion is showing its age.

We’ve now decided that the time is right to make a change. Eagle-eyed users will already have spotted the new LaTeX2e GitHub page, which is now the master repo for the LaTeX kernel. We’ve not yet frozen the existing GNATS database, but new bugs should be reported on GitHub. (For technical reasons, the existing GNATS bugs list is unlikely to be migrated to GitHub.)

Frank Mittelbach (LaTeX team lead developer) has written a short article on the new approach, which will be appearing in TUGboat soon. As Frank says, we hope that most users don’t run into bugs in the kernel (it is pretty stable and the code has been pushed pretty hard over the years), but this new approach will make reporting that bit easier and clearer.

Accompanying the move of LaTeX2e to GitHub, the LaTeX3 Subversion repository has also been retired: the master location for this is also now on GitHub. So everything is in a sense ‘sorted’: all in one place.

Of course, the team maintain only a very small amount of the LaTeX ‘ecosystem’: there are over 5000 packages on CTAN. To help users know whether a bug should be reported to the team or not, we have created the latexbug package.  An example using it:


\RequirePackage{latexbug}

\documentclass{article}

\begin{document}

Problems here

\end{document}

will give a warning if there is any code that isn’t covered by the team (and so should be reported elsewhere). We hope this helps bugs get to the right places as easily as possible.

I handled most of the conversion from Subversion to Git, and I’d like to acknowledge SubGit from TMate Software for making the process (largely) painless. As LaTeX is an open source project, we were able to use this tool for free. We used SubGit for the ‘live’ mirroring of LaTeX3 to GitHub for several years, and it worked flawlessly. The same was true for the trickier task of moving LaTeX2e: the repo history had a few wrinkles that we slightly more difficult to map to Git, but we got there.

l3build development picks up the pace

The LaTeX team have over the past three years created l3build, a ‘proper’ tool which takes our previous testing and release scripts and converts them into some that can be used more widely of LaTeX developers. I talked about the early work some time ago, and Frank Mittelbach and Will Robertson also wrote about it for TUGBoat.

Promoting l3build as a general tool means that new ideas come up, and we’ve been working on that (as well as other things) quite a bit. To keep developments clear, we’ve recently moved the l3build code to a new home on GitHub. This means it’s now separate from the main LaTeX3 repository, but that the history is clearer. This change has meant new ideas have come ‘out of the woodwork’, and have started accumulating in the issue tracker. It looks like an exciting time for l3build: I’m expecting more features to appear and for that to help new developers pick it up as their release technology. Hopefully the result will be more well-designed and tested LaTeX code.

TeX Live 2017 Pretesting

Eager TeX users will have noticed that a few days ago TeX Live 2016 updates were frozen for ever. We now have the pretest available for TeX Live 2017. As always, using pre-release software is not without risk, but as you can install it in parallel with the older releases there is not a big problem. The LaTeX team will be updating a few things on CTAN to go into the new release, and I’ll probably mention some of that in future posts. A quick look over the changes tells us that there are minor (and perhaps not-so-minor) engine changes to explore: I’m particularly keen to try out the new XeTeX math mode approach, using HarfBuzz.

Hosting upgrade

As I mentioned a little while ago, I’ve moved the hosting for my blog and added https access as-standard. Doing that, I of course had to take a stab at how big a hosting package to buy. I get a steady set of hits, according to WordPress’s JetPack plugin about 5000/month. So I went for a hosting package that would easily cover that.

However, it seems that somewhere there are some more visitors! I got a mail from SiteGround saying that the site’s been using too much CPU time based on what I’ve paid for. Looking over the stats, this is not anything about my setup but is one way or another ‘real’ hits. I can’t be sure if they are real people or spam-like bots, of course, but there’s only one solution: upgrade my hosting account. Hopefully this is all transparent to readers: should mean things continue to work smoothly.

Checking over the beamer codebase

Anyone who is watching the beamer GitHub repository will notice quite a lot of checkins, starting from the beginning beamer.cls and working forward. Most of these are ‘internal’ changes, so readers might wonder what is going on.

I’ve been involved with beamer for a while, but have not really taken a good look over the code yet. Several of the entries in the issue list are quite subtle, and it’s clear that a proper tidy-up of the code is needed to sort them out. That means addressing several internal inconsistencies, but it’s also helpful for me to get the code into a form I’m used to. So there are a mix of cosmetic changes in with some real improvements in the code.

Hopefully I’ll not introduce and new issues doing this work. However, it’s not easy to avoid changing behaviour in LaTeX, especially as beamer is somewhat delicate in the first place. So if anyway is keen to help with the work, simply grabbing the development code from time to time and making sure it doesn’t break existing presentations would be very helpful!

Standard font loading in LaTeX2e with XeTeX and LuaTeX

The LaTeX Project have been making efforts over the past few years to update support in the LaTeX2e kernel for XeTeX and LuaTeX. Supporting these Unicode-enabled engines provide new features (and challenges) compared to the ‘classical’ 8-bit TeX engines (probably pdfTeX for most users). Over recent releases, the team have made the core of LaTeX ‘engine-aware’ and pulled a reasonable amount of basic Unicode data directly into the kernel. The next area we are addressing is font loading, or rather the question of what the out-of-the-box (text) font should be.

To date, the LaTeX kernel has loaded Knuth’s Computer Modern font in his original ‘OT1’ encoding for all engines. Whilst there are good reasons to load at least the T1-encoded version rather than the OT1 version, using an 8-bit engine using the OT1 version can be justified: it’s a question of stability, and nothing is actually out-and-out wrong.

Things are different with the Unicode engines: some of the basic assumptions change. In particular, there are some characters in the upper-half of the 8-bit range for T1 that are not in the same place in Unicode. That means that hyphenation will be wrong for words using some characters unless you load a Unicode font. At the same time, both LuaTeX and XeTeX have changed a lot over recent years: stability in the pdfTeX sense isn’t there. Finally, almost all ‘real’ documents using Unicode engines will be loading the excellent fontspec package to allow system font access. Under these circumstances, it’s appropriate to look again at the standard font loading.

After careful consideration, the team have therefore decided that as of the next (2017) LaTeX2e release, the standard text font loaded when XeTeX and LuaTeX are in use will be Latin Modern as a Unicode-encoded OpenType font. (This is the font chosen by fontspec so for almost all users there will no change in output.) No changes are being made to the macro interfaces for fonts, so users wanting anything other than Latin Modern will continue to be best served by loading fontspec. (Some adjustments are being made to the package to be ready for this.)

It’s important to add that no change is being made in math mode: the Unicode maths font situation is not anything like as clear as the text mode case.

There are still some details being finalised, but the general approach is clear and should make life easier for end users.