LaTeX Online: Options continue to grow

The idea of using ‘The Cloud’ for working with documents is very much on the rise. For collaborative work, particularly with less-experienced users, the idea of leaving things like version control ‘built in’ is very attractive. This approach is also a good way to use LaTeX on portable devices, where installing a TeX system may be tricky.

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

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.

Extending biblatex to support multiple scripts

As regular readers will know, I’ve taken an interest in biblatex since it was first developed. Since the original author disappeared, I’ve been at least formally involved in maintain the code. So far, that’s been limited to tackling a few tricky low-level TeX issues, but there are some bigger issues to think about.

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:


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:


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

Clipping support in XeTeX

Clipping boxes is something that TeX does not do: it simply places them on the page. That means that clipping graphics (a pretty common requirement) is actually done by the driver rather than by TeX. The LaTeX graphics package and the driver support that come with it cover quite a lot of cases, and over the years support for a number of other drivers have been written based on the same ideas. However, things are still not 100% identical over all back-ends. A particular gap at the moment is that that XeTeX support code does not offer clipping, because the XeTeX engine does not do this (pdfTeX and LuaTeX both do). Users of pgf might have noticed that it manages to do clipping perfectly happily with XeTeX (or rather they might have wondered why graphics doesn’t when pgf does). Martin Scharrer and I looked at this a while ago for his adjustbox package, and worked out what is actually needed: some PostScript specials in a xdvipdfmx wrapper. The same basic idea is now being integrated into xetex.def, the driver support code used by graphics. This will go to CTAN soon, but some testing would be good. The updated file is available now, so I’d encourage intrepid readers to download and test it!