siunitx development: Notes for my future self

Working on siunitx over the years, I’ve learnt a lot about units and how people want to typeset them. I’ve also realised that I’ve made a few questionable choices in how I’ve tackled various problems. With one eye to future LaTeX3 work, and another to what I might still improve in siunitx, I thought it would be interesting to make a few notes about what I’ve picked up.

  1. Sticking to math mode only would be a good idea. The flexibility that the package offers in terms of using either math or text mode is very popular, but it makes my life very tricky and actually makes some features impossible (TeX only allows us to reliably escape from math mode by using a box). It’s also got some performance implications, and the more I’ve thought about it, the more I realise that it was probably not the best plan to allow both choices.

  2. A different approach to the \boldmath issue would be sensible. Currently, one of the reasons I use a switch from text to math mode internally is that it allows ‘escaping’ from \boldmath. However, that’s probably not the best plan, as it again introduces some restrictions and performance hits, and I think is very unlikely to actually be helpful!

  3. The default number parser should be simple and quick: complex parsing should be an option. As it stands, the parser in siunitx is quite tricky as it does lots of things. A better approach would be to only deal with digit separation ‘out of the box’ (so not really parsing at all), and to allow things like uncertainties, complex numbers and the like as add-ons.

  4. Tables really need a separate subpackage. Dealing with tables of numbers was never really my aim, and I think much clearer tack would be to have some of the internals of the number parse accessible ‘publicly’, then build the table functionality up separately.

  5. The unit parser works very well: don’t change it! Although people ask me mainly about numbers and tables, the real business end of siunitx is the unit parser/formatter. It’s basically spot-on, with only really minor tune-ups needed.

Probably most of this has to wait for a ‘real’ LaTeX3 numbers/units bundle: I can’t break existing documents. However, I’ve got a few ideas which can be implemented when I get the time: watch this space.

Presenting visual material

I’ve recently been thinking about how best to present ‘visual’ material: presentations, lectures and academic posters. As a ‘LaTeX regular’ I tend to do that in LaTeX (using beamer), but in many ways what I’ve been thinking about is entirely independent of the tool I use. Looking around the TeX world, I found a couple of very interesting articles in the PracTeX journal, one on posters and one on presentations. As you might expect, they contain some ‘technical’ advice but are worth a read whatever tool you use to make your visual material. (Many people who use LaTeX for articles prefer more visual tools for posters in particular.)


The core idea in the paper on presentations is I guess ‘rolling your own’ in terms of producing your slides. On the the authors is Marcus Kohm, so it’s no surprise that there is a strong focus on using KOMA-Script as a general-purpose class, and making design changes to suit the screen rather than print. There are a couple of reasons suggested for doing this. The first is that, like any ‘pre-build’ approach, it’s easy to just use the defaults of say beamer or powerdot and make a presentation that is very similar to lots of other ones. If you do the design yourself as a ‘one off’ that’s much less likely to be a concern. The other argument was that in some ways dedicated presentation classes make it too easy to use lots of ‘effects’ (such as the beamer overlay concept I looked at recently).

I’m not sure I’d want to make my own slides from scratch every time I make a presentation: there are reasons that there are dedicated classes. However, I’d say the points about design and ‘effects’ are both valid. I increasingly use pretty ‘basic’ slides, which don’t have much in the way of ‘fancy’ design or dynamic content, and find that these work just as well if not better than more complex ones. Overlays and similar do have a use, and I do use them when they make good sense, but that’s actually pretty rare.


The message in the article on posters is in some ways the same as the presentation one: the standard designs don’t work that well. Academic posters tend to be very text-heavy, and a multi-column design with a few small graphics is one you see repeated a lot. The article suggests a radically-different approach: essentially no words and just graphical elements. That’s not necessarily LaTeX’s strength, but the authors do a goo d job using TikZ to showcase their argument.

I’ve never quite had the nerve to make a poster with essentially no text. However, I do see the point that mainly graphical posters in many ways work better than putting your entire paper on the wall. There’s always that worry that once a poster goes up, you can’t be sure you’ll be there to talk to anyone interested and so a few words are in some ways a ‘safety net’.


Both articles give you something to think about. Even if you do all of your slides and posters in visual tools (PowerPoint, KeyNote, Illustrator, etc.), the core messages are still valid. I’d say we can all learn a little here: worth a read!

Programming LaTeX3: A summary so far

Use of the LaTeX3 programming layer ‘expl3’ in LaTeX2e packages is continuing to grow. Ideally, the team would have a nice easy-to-follow Programming LaTeX3 book to support this, but as the language is still developing and because writing such a guide is hard we are not in that position just at the moment. At the moment, the nearest we get is a series of posts I wrote here a little while ago now, trying to at least put some basics down. What I’d like to build up is a ‘self-contained’ story, based on the idea that the reader knows how to use LaTeX as an ‘end user’ (making documents), but with no particular assumptions about programming. I’m hoping to look again at some of these topics in the coming months, but for the moment it seems like a good idea to summarise what we have so far.

To date, the series covers:

The posts run basically in order, so if you are looking to learn then start with the first one and work your way down.

Of course, looking back I think some revision would be handy: for example, now we have an FPU it might be useful to cover that around the same point as integers. I guess what might be sensible is to look seriously at putting together something more structured which can be revised: perhaps it is time for that book!