I started out with Subversion, then moved to Mercurial when I got involved in beamer maintenance. The idea is the same whatever system you are using: by keeping a track of changes in the code you help yourself in the long term, and make it easier for other people to help too. Mercurial is one of several ‘distributed’ version control systems (DCVS) that have been developed over the last few years. The idea is that each ‘repository’ (copy of the code) has the history with it, and so is independent of any server. You can still send your changes to a server, and that is very popular, but you don’t have to. Sending code to a public server makes it easy to let other people get involved, report issues and so on, and there are lots of sites that will help you do this.

I picked Mercurial over the other leader, Git, mainly because the other guy involved in looking after beamer went this way and put the code on BitBucket. At the time, BitBucket did Mercurial while GitHub did Git. BitBucket changed hands a little while ago now, and they brought in Git support. They’ve now moved to make Git the ‘standard’ repository type. That tells me that Git is likely to ‘win’ as the most popular DCVS (it’s looked that way for a while), and so it’s time to reconsider my use of Mercurial.

It turns out that moving from Mercurial to Git is pretty easy: there is a script called fast-export that does the job. Converting the code itself is therefore easy: run the script (you need a Unix system, so on Windows I’m using a virtual Ubuntu machine with VirtualBox). Life gets a bit more interesting, though, if you want to keep your issues database. BitBucket does offer issue import and export, but no easy way to convert from Mercurial to Git. At the same time, the way that the two systems refer to individual commits means that if you don’t edit your issues, any links to the commits will be messed up. That means that its as easy to move to GitHub as it is to stay on BitBucket. So that’s what I’ve decided to do (GitHub is pretty popular with other LaTeX developers). I’m working through my repositories, converting to Git and uploading to GitHub, then copying the issue information by hand and doing minor edits. That includes making sure that I keep the links which show how I fixed things. Apart from siunitx, my packages don’t have a lot of issues (no more than a dozen each), so I can do that by hand without too much work. I’d a bit surprised no-one has written a script to do this, but at least it will not take too long. I’d expect everything except siunitx to be moved by the weekend, and even this ‘big job’ to be done within a couple of weeks.

Port OpenType layout from ICU LayoutEngine to HarfBuzz. HarfBuzz is actively maintained and generally have much wider support for
OpenType spec, the switch fixes a number of OpenType bugs:

• Support version 2 OpenType Indic specs.
• Many other Indic OpenType bugs, and support for the latest additions to OpenType spec.
• Incorrect application of contextual features.
• Incorrect kerning in fonts that has both old “kern” table and new GPOS “kern” feature.
• Allow suppressing Latin ligatures with ZWNJ.
• Support for variation selectors.
• Support for user-specified features with complex scripts.

If you are familiar with layout engines, you’ll know that while ICU has worked very well for XeTeX from day one, it’s no longer being developed while HarfBuzz is being developed. More importantly, HarfBuzz is supported by the open source community well beyond the TeX world, so by moving in this direction XeTeX gets the benefits of the efforts of many other people: part of the point of open source software. I’m sure it’s been a big effort making this change: I’m looking forward to testing it out.

The other headline change, at least for Mac users, is moving to Core Text rather than ATS/ATSUI. Apple have dropped support for the latter, so there was a worry about building XeTeX on the Mac in the future. That’s now sorted, and means XeTeX should work as a 64-bit application on the Mac in future.

If you read the full announcement you’ll see there are lots of other changes and bug fixes. Congratulations to Khaled on this: it’s great to see that XeTeX continues to develop, and that several features have been added to make working with XeTeX and LuaTeX seamlessly are now there.

There are now several online services, all of which seem to offer a core set of idea (an editor, previewer and TeX system for compiling, and almost certainly version control). Keeping up with the different services is tricky: I’ve come across

• SpanDeX
• ShareLaTeX
• writeLaTeX
• ScribTeX (merging with ShareLaTeX)

All of them offer those core services, and some advertise other goodies such as DropBox integration (SpanDeX does).

What people want to know is probably ‘which service is best’. Some of these have been round for a little while now, but none can claim a long history, so at the moment there’s probably no one clear leader. Not everyone will be comfortable with an online service: letting other people store your data is not something that’s risk-free, while if you want the latest version of every package you use, you’re likely to need to have your own set up.

I’d love to hear people’s experiences of these services: my colleagues don’t use LaTeX, so I don’t have the opportunity to test out the big ‘selling points’ of these sites.

Philip Kime, lead Biber and biblatex developer, is keen to extend the LaTeX end to supporting multiple scripts. The Biber end is already done (in the ‘burning edge’ version), and writes to the .bbl file in the format:

 \field{form=original,lang=default}{labeltitle}{Title}
 \list{form=original,lang=default}{location}{1}{%
   {Москва}%
 }
 \list{form=romanised,lang=default}{location}{1}{%
   {Moskva}%
 }

However, that presents a big issue: how to do that without breaking every existing style. Supporting scripts means we need an additional argument for a very large number of commands: some of them need to have two optional arguments, and some of them need to be expandable:

\iffieldundef[form=original,lang=default]{....}

Reading (two) optional arguments and working through keyval options expandably is tricky, which is where I come in. The natural way for me to solve the first problem is to use LaTeX3, and the xparse package. However, that’s a big change for biblatex, so before I (and the rest of the biblatex team) go for this I though it would be worth raising the issue and looking for opinions. The alternative is to write the code into biblatex directly, but it’s complicated and as I’ve already done the job once I’m reluctant to do this!

So, what I want to know is ‘What do users think?’ Is it reasonable to require xparse as part of `biblate

The biggest change is that you can now register an account, and use this to vote on packages. I’ve of course registered already, and taken a very quick look at the voting system. I notice that at the moment the system doesn’t spot that I’m the author of some packages, so can vote on them! Of course, I’m not going to do that, and if there are lots of people voting it won’t matter.

I got a bug report for siunitx a little while ago about interaction with the bidi package. That pushed me to look at something I’ve been wondering about for a while: what we need to do in the LaTeX3 codebase to allow for multiple directions (particularly right-to-left, which as bidi shows should be usable directly in LaTeX). It’s turned out that good documentation on the various primitives available is not so easy to come by, and that there is a lot to get your head around. Luckily, I’ve had some very useful feedback from a range of people, including John Plaice (one of the authors of Omega). It also turns out that not everything is quite settled in engine support for multiple directions, so asking questions is pretty important.

For a single package upload, that process simply means a little bit of a delay between me saying that something is fixed and everyone being able to use it. However, where there are linked changes in more than one package then life gets a bit more complicated. A classic situation is siunitx, which uses the LaTeX3 programming environment. I do the releases for LaTeX3 so if there is an issue which needs a change in both siunitx and the LaTeX3 code both get updated on CTAN at the same time. However, it’s not unknown for TeX Live or MiKTeX to pick up only one change initially, leading to issues for end users. That’s a pain, but there is little I can do about it as I don’t control that process.