# Some TeX Developments

Coding in the TeX world

## 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:

`````` \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

Written by Joseph Wright

February 10th, 2013 at 11:45 am

Posted in biblatex,LaTeX

Tagged with

### 6 Responses to '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:

`\usepackage{fixbiblatex}`?

Brent Longborough

10 Feb 13 at 1:43 pm

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?

Simon Spiegel

11 Feb 13 at 7:11 am

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.

Patrick Häcker

11 Feb 13 at 4:45 pm

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.

Will Robertson

12 Feb 13 at 3:16 am

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…?

Bruno Le Floch

5 Mar 13 at 12:00 pm

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”?

Canageek

28 Apr 13 at 6:08 pm