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

7 thoughts on “Extending biblatex to support multiple scripts

  1. That’s a very difficult call.

    If one rephrases the question as ‘Is it reasonable to expect xparse to be available in the great majority of TeX installations’, I think the answer is probably ‘yes’.

    But might it be safer (if possible!) to implement as a patch:


  2. Requiring xparse doesn’t really seem that big a deal to me. Modern installations have it and since biblatex always requires it biber counterpart a potential always needs to be up to date.

    In terms of promoting LaTeX concepts using for biblatex certainly seems like a good idea.

    A more conceptual question: I was under the impression – and I might be completely wrong here – that the etoobox package partly overlaps with some LaTeX 3 packages in functionality. Does it conceptually make sense to mix etoolbox and LaTeX 3?

  3. From a user perspective, I think that would be ok, as most of the time either both packages are available or not.

    From a developer perspective: Please go ahead, because the more “large” packages use xparse, the smaller is the disadvantage to use xparse in “small” packages (performance when loading, package dependency, etc.). Using such high-quality packages will increase package developer’s efficiency.

  4. Definitely makes sense to me to load xparse; code duplication isnt a good idea and bleeding edge biblatex users are bound to have uptodate systems. Many biblatex users probably load siunitx anyway!

    Simon: while it’s true that etoolbox and expl3 overlap (in some areas considerably), xparse on its own is a different story. I agree, conceptually it would get confusing to mix biblatex internals with expl3 unless it was a complete port; using xparse on the other hand doesnt require the use of expl3 as a programming environment, let alone the funny catcodes that expl3 is (in)famous for.

  5. One thing I don’t get, there, is that it seems that you need expandable keyval parsing. I thought we only had non-expandable code in l3keys2e…?

  6. Just one point you might want to keep in mind: You shouldn’t be asking yourself “How many LaTeX installs lack xparse” you should be asking yourself “How many LaTeX installs that will have the newest version of BibLaTeX lack xparse?”

    Think about it: There are lots of journals and such that use legacy LaTeX systems for preservation reasons. However, they aren’t going to have BibLaTeX, let alone the newest version. So, what you have to ask is “How many installs would choose to update one new package, but not another”?

  7. An update: In the end, xparse was the only thing that worked nicely. I tried to minimise its use to keep the biblatex source fairly minimalist but without xparse, this would have been hard. I now have a beta working branch of biblatex 3.0 which includes multiscript support. It should be backwards compatible with the 2.x branch but a little slower as it has to do a lot more internally to keep track of script stuff. I have tested it with the APA style test document and I can reproduce an identical PDF when compared with the 2.x version (and I mean identical, tested with professional PDF comparison software). This is far from exhaustive testing though. I next plan to POC this branch by changing the APA style to use the new features and then I have to document 3.0. When this is done, I’ll announce and ask for testing. Biber 2.0 will be required.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.