New TeXworks binaries

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.

Supporting ACS submissions

My achemso package has evolved over time to work quite well for submitting papers to the American Chemical Society (ACS). However, I still get feedback about issues with the submission system. A lot of this comes from the fact that I write the package without any direct input from the ACS. So any issues tend to be brought up by users. The ACS publish around 30 journals, each with its own rules, and I have to work out what each one wants! Not an easy task: I’ve submitted to a couple, and never as the lead author. It’s a challenge, but I hope that I’m doing more good than harm.

Speed versus clarity

Programming complex functions in TeX tends to involve a lot of manipulation of variables. At the low level, TeX doesn’t provide a lot of variable types, and so most things are done using macros. This means that a lot of array or record-type work is done by using large numbers of macros and giving them appropriate names. This is fast, as there is no need to recover data from a larger structure, but doesn’t make for easy to read code.

One aim of LaTeX3 is to provide better programming tools built on TeX, and this includes higher-level variable support. If you take a look at the expl3 manual, you’ll find that there is support for ideas such as property lists an sequence stacks. These are, of course, implemented using macro or token registers, but provide some of the more abstract ideas that other programming languages provide for variables. The pay-off is in speed: there will always be a cost to adding layers on top of the TeX basics.

I’ve been worrying about how to use the new structures as I work on siunitx version 2. My original code uses lots of macros to store things, but the result is that the code is difficult to read and even harder to change. My earlier attempts at improving the code stuck with this approach, but rationalised it into something more systematic. Better than version 1, but I’ve not been entirely happy with the results. I’m now trying again, this time using the high-level variables of LaTeX3 to do things. There is going to be a cost in speed, but I hope that making the code readable will be reward enough. I’m also spotting ways to improve the flow of code, so that there should be less to actually do in the new version. Looking to the future, making the code more maintainable should more than compensate for a little loss of speed. In the end, I’m sure I’ll be asked for more features, and having data structures I can rely on is essential for doing that.

Moving siunitx to LaTeX3 coding

If you take a look at the development version of siunitx, you will find that I’m getting on with moving the code over to using LaTeX3 coding internally. That does not mean that the package will not work using LaTeX2ε: everything still works nicely in a normal LaTeX document! However, it does mean that I can use the new coding ideas to make my life easier, and hopefully the code more robust and a little faster.

I’ve also moved to using my own LaTeX3 keyval package for option handling. I recently added it to the main LaTeX3 code base, so I know that it will be available if LaTeX3 is! Following the pattern for other LaTeX3 keyval settings, I’m changing the original key naming plan somewhat. I’ll probably post more detail on this once things are working a little better. The idea is to use more descriptive key names that then current version of siunitx, for example:

\sisetup{
  group-digits         = true,
  round-mode           = places,
  round-places         = 3,
  separate-uncertainty = true
}

There will be a delay of a week as I’m on holiday, then I hope to get the experimental code doing almost everything that the current release version does. There is going to be a bigger delay as I sort out one idea that has been requested several times. I want to add some floating point stuff, but to do that I need to write support for that for LaTeX3. I have some ideas, but it will take a while to actually do the work.

Keyval methods in LaTeX3

I’ve been working for a while on a method to provide a reasonably powerful method for creating keyval input for LaTeX3. This has been going under the working title “keys3”, but yesterday I took the plunge and added the code to the LaTeX3 development repository. For the moment, this can only be accessed via SVN, but if the rest of the team are happy with the idea, it will appear in the next snap shot that is sent to CTAN.

The ideas in the new module (now called l3keys) have been inspired by the pgfkeys package. By using keyval methods to create keys, the idea is to make life a lot easier for the programmer. However, things are somewhat modified compared to the pgfkeys package, mainly to try to keep the input syntax simple but powerful enough for most uses. For example, there are separate functions for creating keys and setting them, an idea that all other keyval packages use. So a typical setup block might look like:

\keys_define:nn { module } {  
  key-one   .set:N     = \l_module_one_tl,   % Store input in variable
  key-one   .value_required:,
  key-two   .bool:N    = \l_module_two_bool, % Either true or false
  key-three .code:n    = { Code using an argument #1 },
  key-three .default:n = text
}

while keys are set using:

\keys_set:nn { module } {
  key-one = Value,
  key-two = true,
  key-three
}

Hopefully, the ideas are flexible and clear enough for people to get working with. One thing to notice: the key names are hyphenated. It looks like that will be the “style guide” suggestion for LaTeX3 keys. At some point, I’ll look at writing a TUGBoat article on how everything works.

Detexify 2

Daniel Kirsch has updated his Detexify symbol-finding web page. Daniel says

It is now much more flexible in adding symbols from different packages.
Unfortunately I wasn’t able to import the old training data so
basically the system is empty. But it is now possible to train symbols
explicitly.

The new site looks even more impressive than the first version, if in need of a little training!

TeXworks reaches version 0.1

The TeXworks program has been my main TeX editor for some time, despite having verion number “0.0.0”. There are recently been some work on getting a proper icon sorted out for the program, to replace the place holder. At the same time, Jonathan Kew has moved the version number on to 0.1. Great stuff: I’d already say it’s very usable. There is a Windows build for the latest version curtsey of Alain Delmotte: I suspect Mac and Unix users will have a little longer to wait if they want something pre-compiled.

Avoiding active characters

A while ago, I had a bug report for siunitx, which gives an infinite loop if used with htlatex. It has taken me a while to work out where the problem was, but it comes down to the use of active characters. I’ve given it some thought, and now have a solution that will work in the development version of siunitx. I’m currently reluctant to modify the release version to alter this behaviour, because it is quite a big change. If this is an issue for lots of people, I’ll revisit this, of course.

Hopefully, UTF-8 capable engines (XeTeX and LuaTeX) will mean that the general use of active characters can be avoided. There are a lot of pitfalls, and in general it seems to be much better to steer well clear unless absolutely necessary.

Progress on siunitx version 2

I’ve been doing quite a bit of thinking about siunitx version 2. My original plan was to write everything in standard LaTeX2e code, but the more I thought about things the more it has not looked like such a good idea. siunitx needs a lot of programming tools, and these are almost all available in the experimental LaTeX3 code which is now approaching stability. At the same time, there are still some difficult issues to solve for siunitx, and I’m going to need some more support stuff, I think. So I’ve revised my ideas on how to progress.

Currently, I’m moving the code I have already re-written to use LaTeX3 conventions internally. I’m then going to try to solve the remaining issues for version 2. The aim is to have a package which will run on LaTeX2e, using LaTeX3 internals, so that I can eventually create a LaTeX3-only edition with the same interface ideas. I’m going to try to crack on with things, but it will take a while to solve the remaining issues!