# Some TeX Developments

Coding in the TeX world

## Biblatex: more versatile shorthand lists

One of the useful features of biblatex is shorthands, which can be defined in a BibTeX database and listed in the bibliography. A long-standing request has been to make this even more powerful by allows several different kinds of shorthand, for example for journal abbreviations, general abbreviations, etc. This ability has now been added to the development version of the package, by generalising shorthands to ‘biblists’. Of course, new features always need testing, so it would be great if interested users would grab the code and try it out!

Written by Joseph Wright

March 30th, 2014 at 8:18 pm

Posted in biblatex,LaTeX

## A place for (PGF) plot examples

Not content with running The LaTeX Community, TeXample and texdoc.net, blogging on TeX matters and being a moderator on TeX Stack Exchange, Stefan Kottwitz has now started a new site: pgfplots.net. The idea for the new site is simple: it’s a place to collect great examples of plots, (primarily) made using using the excellent pgfplots package. Why do this? Plots are just graphics, but they are a very special form of graphic with particular requirements. As a working scientist, I really appreciate the need for well-presented, carefully-constructed plots: they can make (or break) a paper.

At the moment, the selection of plots is of course quite small: the site is new and the room for ‘artistic’ work is perhaps a little more limited than in the TeXample gallery. I’m sure it will soon grow, and we can all pick up a trick or two! (Don’t worry: there will certainly be a few plots for chemists. Indeed, you might already spot some.)

Written by Joseph Wright

March 29th, 2014 at 9:37 pm

Posted in LaTeX

Tagged with

## Work on siunitx v3

I recently posted a few ‘notes to myself’ about future directions in siunitx development. With them down in print, I’ve been giving them some serious thought and have made a proper start on work on version 3 of the package. I’m starting where I’m happiest: the unit parser and related code, and am working on proper separation of different parts of the code. That’s not easy work, but I think it should give me a good platform to build on. I’m also working hard to make the new code show ‘best practice’ in LaTeX3 coding: the plan is to have much richer documentation and some test material to go with the new code. Looking forward, that should make creating a ‘pure’ LaTeX3 units module pretty easy: it will be a minor set of edits from what I’m working on now.

I’ve got a good idea of the amount of work I need to do: there are about 17k lines in the current siunitx.dtx, which comes out to around 7.5k lines of code. That sounds like a lot, but as much of what I need to do is more editing that writing from scratch I’m hoping for an alpha build of version 3 some time this summer.

Written by Joseph Wright

March 13th, 2014 at 9:21 pm

Posted in siunitx

## siunitx development: Notes for my future self

with one comment

Working on siunitx over the years, I’ve learnt a lot about units and how people want to typeset them. I’ve also realised that I’ve made a few questionable choices in how I’ve tackled various problems. With one eye to future LaTeX3 work, and another to what I might still improve in siunitx, I thought it would be interesting to make a few notes about what I’ve picked up.

1. Sticking to math mode only would be a good idea. The flexibility that the package offers in terms of using either math or text mode is very popular, but it makes my life very tricky and actually makes some features impossible (TeX only allows us to reliably escape from math mode by using a box). It’s also got some performance implications, and the more I’ve thought about it, the more I realise that it was probably not the best plan to allow both choices.

2. A different approach to the \boldmath issue would be sensible. Currently, one of the reasons I use a switch from text to math mode internally is that it allows ‘escaping’ from \boldmath. However, that’s probably not the best plan, as it again introduces some restrictions and performance hits, and I think is very unlikely to actually be helpful!

3. The default number parser should be simple and quick: complex parsing should be an option. As it stands, the parser in siunitx is quite tricky as it does lots of things. A better approach would be to only deal with digit separation ‘out of the box’ (so not really parsing at all), and to allow things like uncertainties, complex numbers and the like as add-ons.

4. Tables really need a separate subpackage. Dealing with tables of numbers was never really my aim, and I think much clearer tack would be to have some of the internals of the number parse accessible ‘publicly’, then build the table functionality up separately.

5. The unit parser works very well: don’t change it! Although people ask me mainly about numbers and tables, the real business end of siunitx is the unit parser/formatter. It’s basically spot-on, with only really minor tune-ups needed.

Probably most of this has to wait for a ‘real’ LaTeX3 numbers/units bundle: I can’t break existing documents. However, I’ve got a few ideas which can be implemented when I get the time: watch this space.

Written by Joseph Wright

February 27th, 2014 at 9:57 pm

Posted in siunitx

## Presenting visual material

I’ve recently been thinking about how best to present ‘visual’ material: presentations, lectures and academic posters. As a ‘LaTeX regular’ I tend to do that in LaTeX (using beamer), but in many ways what I’ve been thinking about is entirely independent of the tool I use. Looking around the TeX world, I found a couple of very interesting articles in the PracTeX journal, one on posters and one on presentations. As you might expect, they contain some ‘technical’ advice but are worth a read whatever tool you use to make your visual material. (Many people who use LaTeX for articles prefer more visual tools for posters in particular.)

## Presentations

The core idea in the paper on presentations is I guess ‘rolling your own’ in terms of producing your slides. On the the authors is Marcus Kohm, so it’s no surprise that there is a strong focus on using KOMA-Script as a general-purpose class, and making design changes to suit the screen rather than print. There are a couple of reasons suggested for doing this. The first is that, like any ‘pre-build’ approach, it’s easy to just use the defaults of say beamer or powerdot and make a presentation that is very similar to lots of other ones. If you do the design yourself as a ‘one off’ that’s much less likely to be a concern. The other argument was that in some ways dedicated presentation classes make it too easy to use lots of ‘effects’ (such as the beamer overlay concept I looked at recently).

I’m not sure I’d want to make my own slides from scratch every time I make a presentation: there are reasons that there are dedicated classes. However, I’d say the points about design and ‘effects’ are both valid. I increasingly use pretty ‘basic’ slides, which don’t have much in the way of ‘fancy’ design or dynamic content, and find that these work just as well if not better than more complex ones. Overlays and similar do have a use, and I do use them when they make good sense, but that’s actually pretty rare.

## Posters

The message in the article on posters is in some ways the same as the presentation one: the standard designs don’t work that well. Academic posters tend to be very text-heavy, and a multi-column design with a few small graphics is one you see repeated a lot. The article suggests a radically-different approach: essentially no words and just graphical elements. That’s not necessarily LaTeX’s strength, but the authors do a goo d job using TikZ to showcase their argument.

I’ve never quite had the nerve to make a poster with essentially no text. However, I do see the point that mainly graphical posters in many ways work better than putting your entire paper on the wall. There’s always that worry that once a poster goes up, you can’t be sure you’ll be there to talk to anyone interested and so a few words are in some ways a ‘safety net’.

## Conclusion

Both articles give you something to think about. Even if you do all of your slides and posters in visual tools (PowerPoint, KeyNote, Illustrator, etc.), the core messages are still valid. I’d say we can all learn a little here: worth a read!

Written by Joseph Wright

February 4th, 2014 at 8:49 am

Posted in General

Tagged with , ,

## Programming LaTeX3: A summary so far

Use of the LaTeX3 programming layer ‘expl3′ in LaTeX2e packages is continuing to grow. Ideally, the team would have a nice easy-to-follow Programming LaTeX3 book to support this, but as the language is still developing and because writing such a guide is hard we are not in that position just at the moment. At the moment, the nearest we get is a series of posts I wrote here a little while ago now, trying to at least put some basics down. What I’d like to build up is a ‘self-contained’ story, based on the idea that the reader knows how to use LaTeX as an ‘end user’ (making documents), but with no particular assumptions about programming. I’m hoping to look again at some of these topics in the coming months, but for the moment it seems like a good idea to summarise what we have so far.

To date, the series covers:

The posts run basically in order, so if you are looking to learn then start with the first one and work your way down.

Of course, looking back I think some revision would be handy: for example, now we have an FPU it might be useful to cover that around the same point as integers. I guess what might be sensible is to look seriously at putting together something more structured which can be revised: perhaps it is time for that book!

Written by Joseph Wright

February 2nd, 2014 at 10:48 am

Posted in LaTeX3

Tagged with

## The +-overlay syntax and \pause in beamer

with one comment

In a recent post I looked at how to use the + syntax to create flexible overlays in beamer. The key concept of that syntax is to allow dynamic slides to be created without having to hard-code slide numbers. The classic example is to reveal a list an item at a time:

\begin{frame}
\begin{itemize}
\item<+-> This is on the first and all following slides
\item<+-> This is on the second and all following slides
\item<+-> This is on the third and all following slides
...
\end{itemize}
\end{frame}


As I discussed in the earlier post, this is a very powerful way to create overlays (dynamic slides from the same frame source). However, a classic problem people have is combining this with the \pause command. For example, the following creates four slides:

\begin{frame}
\begin{itemize}
\item<+-> This is on the first and all following slides
\item<+-> This is on the second and all following slides
\item<+-> This is on the third and all following slides
...
\end{itemize}
\pause
Text after the list
\end{frame}


Why? If you read the beamer manual, it’s all about the value of \beamerpauses, but if we skip to the key point, you should not use \pause on the same slide as <+-> (or similar).

## Beyond the power of \pause: \onslide

The reason people get into trouble is I think because they imagine \pause as the best way to break ‘running text’ in a frame into overlays. However, \pause is really just the most basic way of breaking up frames and is meant just for the simplest cases

\begin{frame}
Some content
\pause
Some more content
\end{frame}


The moment you introduce other dynamic behaviour, you need more control than \pause offers. Indeed, this is pretty clear in the beamer manual: what people are actually looking for is \onlside.

Unlike \pause, which only knows some basic stuff about slide numbers, \onslide works with the full power of the flexible overlay specification (indeed, an overlay specification is required). So to get text after a list, what is needed is

\begin{frame}
\begin{itemize}
\item<+-> This is on the first and all following slides
\item<+-> This is on the second and all following slides
\item<+-> This is on the third and all following slides
...
\end{itemize}
\onslide<+->
Text after the list
\end{frame}


As we are then using the special + syntax for all of the overlays, everything is properly tied together and will give the (probably) expected result: three slides.

The beamer manual covers other more complex effects using \only, \uncover, \alt and so on, but using \onslide you can do everything you think you can do with \pause but actually have it work when using the + syntax on the slide too!

Written by Joseph Wright

January 28th, 2014 at 7:16 am

Posted in beamer

Tagged with

## beamer development

As many readers will know, I’m a member of the two-man team in charge of maintaining the beamer class (the other team member is Vedran Miletić). Vedran and I took over looking after beamer when it was unmaintained and some important bugs cropped up: lots of people rely on it, so fixes were important. There was a question on the TeX Stackexchange site recently asking about the status of maintenance. It’s a tricky one to tackle in a Q&A, but it does make a good topic for the blog!

Vedran and I are committed to keeping beamer working, and that means fixing bugs as and when we can. At the same time, we are not likely to add much in the way of new feature: small changes over time only. There are a few reasons for that, the single biggest one of which is stability. The beamer class is very widely used, and does a lot of stuff. Making significant changes is therefore tricky, particularly as we don’t have any automated tests. The internal beamer structure contributes a bit here: it’s a complex set up, partly due to some issues in LaTeX2e (why I work on LaTeX3), partly because it has to be and partly as an ‘overhaul’ might have been useful at some stage. (It’s far too late for the latter idea now: any big change would break too many documents.)

The second issue is of course time: both Vedran and I are busy, in my case not only with ‘real life’ but also with other (La)TeX projects! Then of course there is trying to stick to what beamer does: the original design quite deliberately doesn’t do some things, so as ‘auto-flowing’ text.

If you watch the BitBucket site for beamer development, you will see changes, both to fix bugs and (slowly) add new features. That’s not about to change: small changes, ‘little and (relatively) often’, are the order of the day here. Of course, if you have a patch you really want applying, we are always happy to take a look!

Written by Joseph Wright

January 27th, 2014 at 10:05 pm

Posted in beamer

## The beamer slide overlay concept

There was a question recently on the TeX StackExchange site about the details of how slide overlays work in the beamer class. The question itself was about a particular input syntax, but it prompted me to think that a slightly more complete look at overlays would be useful.

A word of warning before I start: don’t overdo overlays! Having text or graphics appear or disappear on a slide can be useful but is easy to over-use. I’m going to focus on the mechanics here, but that doesn’t mean that they should be used in every beamer frame you create.

## Overlay basics

Before we get into the detail of how beamer deals with overlays, I’ll first give a bit of background to what they are. The beamer class is built around the idea of frames:

\begin{frame}
\frametitle{A title}
% Frame content
\end{frame}


which can produce one or more slides: pages of output that will appear on the screen. These separate slides within a frame are created using overlays, which is the way the beamer manual describes the idea of having the content of individual slides varying. Overlays are ‘contained’ within a single frame: when we start a new frame, any overlays from the previous one stop applying.

The most basic way to create overlays is to explicitly set up individual items to appear on a particular slide within the frame. That’s done using the (optional) overlay argument that beamer enables for many document components: this overlay specification is given in angle brackets. The classic example is a list, where the items can be made to appear one at a time.

\begin{frame}
\begin{itemize}
\item<1-> This is on the first and all following slides
\item<2-> This is on the second and all following slides
\item<3-> This is on the third and all following slides
...
\end{itemize}
\end{frame}


As you can see, the overlay specification here is simply the first slide number we want the item to be on followed by a - to indicate ‘and following slides’. We can make things more specific by giving only a single slide number, giving an ending slide number and so on.

\begin{frame}
\begin{itemize}
\item<1> This is on the first only
\item<-3> This is on the first three slides
\item<2-4,6> This is on the second to fourth slides and the sixth slide
\end{itemize}
\end{frame}


The syntax is quite powerful, but there are at least a couple of issues. First, the slide numbers are hard-coded. That means that if I want to add something else in before the first item I’ve got to renumber everything. Secondly, I’m having to repeat myself. Luckily, beamer offers a way to address both of these concerns.

## Auto-incrementing the overlay

The first tool beamer offers is the the special symbol + in overlay specifications. This is used as a place holder for the ‘current overlay’, ans is automatically incremented by the class. To see it in action, I’ll rewrite the first overlay example without any fixed numbers.

\begin{frame}
\begin{itemize}
\item<+-> This is on the first and all following slides
\item<+-> This is on the second and all following slides
\item<+-> This is on the third and all following slides
...
\end{itemize}
\end{frame}


What’s happening here? Each time beamer finds an overlay specification, it automatically replaces all of the + symbols with the current overlay number. It then advances the overlay number by 1. So in the above example, the first + is replaced by a 1, the second by a 2 and the third by a 3. So we get the same behaviour as in the hard-coded case, but this time if I add another item at the start of the list I don’t have to renumber everything.

There are of course a few things to notice. The first overlay in a frame is number 1, and that’s what beamer sets the counter to at the start of each frame. To get the second item in the list to appear on slide 2, we still require an overlay specification for the first item: although I used one, I could have skipped the <1-> in the hard-coded example and nothing would have changed. The second point is that every + in an overlay specification gets replaced by the same value. We’ll see later there are places you might accidentally add a + to mean ‘advance by 1′: don’t do that!

## Reducing redundancy

Using the + approach has made our overlays flexible, but I’ve still have to be repetitive. Handily, beamer helps out there too by adding an optional argument to the list which inserts an overlay specification for each line:

\begin{frame}
\begin{itemize}[<+->]
\item This is on the first and all following slides
\item This is on the second and all following slides
\item This is on the third and all following slides
...
\end{itemize}
\end{frame}


Notice that this is needs to be inside the ‘normal’ [ ... ] set up for an optional argument. Applying an overlay to every item might not be exactly what you want: you can still override individual lines in the standard way.

\begin{frame}
\begin{itemize}[<+->]
\item This is on the first and all following slides
\item This is on the second and all following slides
\item This is on the third and all following slides
\item<1-> This is on the first and all following slides
...
\end{itemize}
\end{frame}


Remember not to overdo this effect: just because it’s easy to reveal every list line by line doesn’t mean you should!

## Repeating the overlay number

The + syntax is powerful, but as it always increments the overlay number it doesn’t allow us to remove the hard-coded numbers from a case such as

\begin{frame}
\begin{itemize}
\item<1-> This is on the first and all following slides
\item<1-> This is also on the first and all following slides
\item<2-> This is on the second and all following slides
\item<2-> This is also on the second and all following slides
...
\end{itemize}
\end{frame}


For this case, beamer offers another special symbol: ..

\begin{frame}
\begin{itemize}
\item<+-> This is on the first and all following slides
\item<.-> This is also on the first and all following slides
\item<+-> This is on the second and all following slides
\item<.-> This is also on the second and all following slides
...
\end{itemize}
\end{frame}


What happens here is that . can be read as ‘repeat the overlay number of the last +‘. So the two + overlay specifications create two slides, while the two lines using . in the specification ‘pick up’ the overlay number of the preceding +. (The beamer manual describes the way this is actually done, but I suspect that’s less clear than thinking of this as a repetition!)

Depending on the exact use case, you might want to combine this with the ‘reducing repeated code’ optional argument, with <.-> as an override.

\begin{frame}
\begin{itemize}[<+->]
\item This is on the first and all following slides
\item<.-> This is also on the first and all following slides
\item This is on the second and all following slides
\item<.-> This is also on the second and all following slides
...
\end{itemize}
\end{frame}


## Offsets

A combination of + and . use can be used to convert many ‘hard-coded’ overlay set ups into ‘relative’ ones, where the slide numbers are generated by beamer without you having to work them out in advance. However, there are cases it does not cover. To allow even more flexibility, beamer has the concept of an ‘offset’: and adjustment to the number that is automatically inserted. Offset values are given in parentheses after the + or . symbol they apply to, for example

\begin{frame}
\begin{itemize}
\item<+(1)-> This is on the second and all following slides
\item<+(1)-> This is on the third and all following slides
\item<+-> This is also on the third and all following slides
\end{itemize}
\end{frame}


Notice that in this adjustment only applies to the substitution, so both the second and third lines above end up as <3-> after the automatic replacement. If you try the demo, you’ll also notice that none of the items appear on the first slide!

Perhaps a more realistic example for where an offset is useful is the case of revealing items ‘out of order’, where the full list makes sense in some other way. With hard-coded numbers this might read

\begin{frame}
\begin{itemize}
\item<1-> This is on the first and all following slides
\item<2-> This is on the second and all following slides
\item<1-> This is on the first and all following slides
\item<2-> This is on the second and all following slides
...
\end{itemize}
\end{frame}


which can be made ‘flexible’ with a set up such as

\begin{frame}
\begin{itemize}
\item<+-> This is on the first and all following slides
\item<+-> This is on the second and all following slides
\item<.(-1)-> This is on the first and all following slides
\item<.-> This is on the second and all following slides
...
\end{itemize}
\end{frame}


or the equivalent

\begin{frame}
\begin{itemize}
\item<+-> This is on the first and all following slides
\item<.(1)-> This is on the second and all following slides
\item<.-> This is on the first and all following slides
\item<+-> This is on the second and all following slides
...
\end{itemize}
\end{frame}


As shown, we can use both positive and negative offsets, and these work equally well for + and . auto-generated values. You have to be slightly careful with negative offsets, as while beamer will add additional slides for positive offsets, if you offset below a final value of 0 then errors will crop up. With this rather advanced set up, which version is easiest for you to follow will be down to personal preference.

Notice that positive offsets do not include a + sign: remember what I said earlier about all + symbols being replaced. If you try something like <+(+1)>, your presentation will compile but you’ll have a lot of slides!

## Summary

The beamer overlay specific can help you set up complex and flexible overlays to generate slides with dynamic content. By using the tools carefully, you can make your input easier to read and maintain.

Written by Joseph Wright

January 17th, 2014 at 8:06 pm

Posted in beamer,LaTeX

Tagged with

## The LaTeX Companion as an eBook

Many long-term LaTeX users have on their bookcase a copy of The LaTeX Companion, an excellent guide to ways to tackle a wide variety of problems in LaTeX. Having it available electronically has been something that many people have wanted, so I was very pleased when I heard from the lead author, Frank Mittelbach, that this was in the offing. The electronic version, as a PDF or in eBook format (ePub and Mobi), is now available from InformIT, the publisher’s online store.

The price is very reasonable: $23.99, with a discounted price ($14.99) available until the end of the year using code LATEXT2013. For that, you get all three formats in DRM-free form: the PDF is watermarked but otherwise identical to the current print version (the 2nd edition). It’s not a new edition: the (excellent) text is that written by Frank and the rest of the team in 2004. For many purposes, that makes very little difference as LaTeX is generally very stable, but if you are interested in biblatex, TikZ, LuaTeX or other ‘new’ developments in the LaTeX world then perhaps it’s not the book for you.

As the PDF is identical to the print version, it works best on bigger screens where you can give it the full width and size it needs. The eBook forms work better on dedicated readers, but at the cost that the code examples are inserted there as pictures. There’s a good reason for that: only in the PDF is the typography done by TeX, so to see the real results in the eBook forms means that pictures are the only way to go. You get all the internal links you’d expect in all of the formats: the table of contents to chapters, references to the bibliography and so on. Having all three formats for one price means you can both take advantage of the flexibility of eBooks and have a copy with high quality typography all available to you where ever you go. Being electronic, you can also search the text (only the PDF lets you search the examples as only there are they not pictures.)

There’s very little downside to the electronic copy: the cost is good, the restrictions are minimal and the text itself is of course excellent.

Written by Joseph Wright

October 25th, 2013 at 8:41 pm

Posted in LaTeX