siunitx version two: Snapshot 2 (SVN 62)

As promised, a second snapshot of siunitx version 2 is now available:

This adds functioning unit processing to the test code, as well as sorting bugs in the previous snaphot (for example, a few problems with numbers). Testers will see that version 2 will provide a lot more units by default: this is a result of changing the method for defining units, making it much easier to avoid clashes with other packages. As with snapshot one, there are a lot of gaps in the existing code (for example, backward-compatibilty!). Feedback is very welcome.

“Programming in Lua”

Over the week-end, the copy of Programming in Lua that I’d ordered arrived at the bookshop. So I’ve been able to make at least a small start on the book, and get some of the ideas into my head. Having looked at the first 40 or so pages, I can see why Lua has been chosen for integration with TeX as LuaTeX. Some TeX concepts are also Lua concepts (such as the scope of variables and the ability to re-define anything), and so the fit between the two languages looks good. How that translates in practice I’ll have to see.

What I have found to date is that you really don’t want to be a beginner if you pick up Programming in Lua. The book starts with a lot of pretty complicated programming ideas, and without some background I’d be in trouble. Luckily I’ve picked up bits and pieces over the years (from Basic, C and Perl, amongst other things), and so I’m not totally lost. But for a book aimed at people starting off with the language, it is tough going.

The arrival of the book happily coincides with the release of LuaTeX 0.36.0, as announced on the LuaTeX mailing list. There are a number of changes aimed at making more changes in the future, but at least I can now begin to understand what some of them mean!

A guide to key-value methods

I have a second draft for TUGBoat on the go at the moment: an article on implementing key-value input. These are widely used in LaTeX packages, but are also usful in plain TeX. As well as the original keyval package, we have xkeyval, kvoptions and kvsetkeys for managing key–value input. However, actually getting started with these as a LaTeX programmer can be somewhat difficult. The aim of the article is to lower the barrier to getting going with key-value methods. As well as the keyval-based information, the pgfkeys package (part of the pgf bundle) is also covered (thanks to Christian Feuersänger).

LaTeX3 overview updated

A while ago, I drafted an overview article on LaTeX3 for TUGBoat. Since then, there have been some key changes to the current LaTeX3 code, and so I’ve slightly revised the article. It is aimed as a very general overview of what is available at the moment, and is available as a PDF and in source form.

keys3 updated

As I said earlier in the week, I’ve been revising my key3s package, which is an experimental keyval system in LaTeX3 syntax. I was initially aiming to keep things up to date with recent changes in LaTeX3, but the more I looked the more there was to do. So the new version is rather different to that of a week ago. I’ve dropped a number of things that I’d taken from pgfkeys (part of the pgf bundle) that, with thought, I’m not happy about. That is not to say that some things wouln’t re-appear: I still want to look at some of the new stuff in the development version of pgfkeys.

I’ll probably upload the package to CTAN over the weekend, but for the moment the interested can grab:

• The documentation (.pdf)
• The source file (.dtx)
• Docstrip extration file (.ins)
• Demonstration/test file (.tex)

Google Summer of Code

The TeX Users’ Group (TUG) is applying (for the second year) to be a mentoring organisation for the Google Summer of Code (GSOC). Currently, the TUG web page for the GSOC lists seven very different potential projects. All of them look both exciting and challenging. Hopefully, this will convince Google to approve TUG as a mentoring organisation, and will then attract keen students!

keys3 changes

Having looked again at keys3, there are a number of things I’m not happy with. Some of these are things will result in dropping functionality that I don’t believe is truely reliable. There will be a lot of commits to the source repository in the next few days as I alter what there is there. I’ll post an update once I’m reasonable happy again.

Breaking lines in siunitx version 2

Line breaks between units and values are frowned upon by those “in the know”, as the unit–value combination is mathematically one entity. Despite that, in reality this is a feature I’ve been asked for in siunitx.The way I’m implementing things, this is not technically difficult to implement. With a suitable warning, I will include the ability to break between units and values in siunitx version 2.

The other place you could place breaks is between different units (assuming a space is being used as the unit separator). This is much more problematic for a number of reasons. First, unlike between numbers and units, the inter-unit separator might be one of various things. The space between a value and a unit is always some kind of white space, and is always expected by the reader. So working out if a break is sensible would not be easy. Second, siunitx needs to handle two types of unit input, units as macros and literal input. I’ve steered away from processing literal units for various reasons, and reliably breaking both types of input looks difficult. Third, there is a technical problem. Simplifying how siunitx works, currently units are actually printed by some code that does:

\hbox{%
% Some font set up work for maths mode
\ensuremath{%
\mathrm{%
unit \, unit \, unit
}%
}%
}

when printing in maths mode (the default). The key point is that everything needs to be inside an \hbox so that the formatting of maths can be influenced correctly. So breaking units here is not possible. To get around this, I’d need to print each unit separately, with the spaces outside the box. This looks slow and unreliable. All things considered, I’m minded to keep the current approach to units: the unit is a non-divisible block.

keys3: More work needed?

A while ago, I did a bit of work on converting the pgfkeys package (part of pgf) to LaTeX3 syntax, and called the result keys3. Some things have changed in LaTeX3 since then, and I also have an outstanding list of things to think about adding to keys3. On top of that, I’ve spotted at least one bug (inherited from pgfkeys!). So the question is: is it worth fixing them? At the moment, keys3 might not go anywhere, so I’m not sure. Thoughts, anyone?

Change for the better

There have been a couple of discussions recently, both concerned with “change for the better”. The first, on the LaTeX-L list, is about adding the ability to convert EPS graphics to PDF “on the fly”. The suggestion is to have the graphicx package load epstopdf automatically, and to arrange a limited version of \write18 that will only allow known commands to be run. That should let ordinary users include EPS files with pdfLaTeX without needing to worry about the detail. A good thing, but it does raise one issue. People who use updated versions of LaTeX will have this feature, but if they send their files to others who don’t, things won’t “just work”. This can’t really be avoided: if you add a new feature, then people without the update get a different result from those who do have it. Not much you can do, if you want any change at all!

The second change has come up on the LaTeX Community and comp.text.tex. The latest version of natbib is rather more careful than earlier versions about the BibTeX style file used. This means that the latest version gives an error, where older versions silently change settings to “mind-read” what the user wants. This has lead to a lot of confusion, and some people recommending replacing the newer version with the old one! In the end, the change here is also for the better: the error that is causing problems (where the BibTeX style needs the “numbers” option, and it’s not been given) is perfectly sensible. But it also shows the dangers of mending or improving things: people get used to the sub-optimal behaviour, and think something is wrong when it is sorted out!

Conclusion: make change for the better, but be ready for complaints.