Some TeX Developments

Coding in the TeX world

The beamer slide overlay concept

with 2 comments

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

with 3 comments

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

LaTeX Tutorial videos from ShareLaTeX

with 2 comments

Learning LaTeX without a ‘local guide’ can be a challenge: it’s one of the reasons I’m involved in running training courses for UK-TUG. The people behind ShareLaTeX have decided to make a series of videos aimed at newer LaTeX users, covering the basics of LaTeX use, writing a thesis and also some more advanced topics (TikZ and beamer, for example).

There are currently about 25 videos, and I’ve watched all of the ‘basic’ ones (the LaTeX beginners series and the thesis series). The quality and presentation is pretty good: as well as well produced videos there are also transcripts for all of them, and of course the demos are available on ShareLaTeX. Of course, there are a few things I’d tackle differently, but the overall picture is pretty impressive. They’ve put a lot of work into the videos, and if you work through carefully (and take time to try the demos yourself) them I think you’ll get a good grounding in using LaTeX.

Written by Joseph Wright

September 15th, 2013 at 10:53 am

Posted in LaTeX

Tagged with , ,

Beamer and \subsubsection

without comments

I’m hoping to address a few bugs in beamer over the next few days. One category that is always tricky is things linked to using \subsubsection. If you’ve read the beamer manual carefully, you’ll know that the original author of the class really didn’t want people to use \subsubsection in talks. However, he also didn’t ban it entirely, leaving me with a tricky situation. The problem is that while \subsubsection works, many of the things you might expect to happen from the relationship between \section and \subsection fail with \subsubsection, and from the code that may well be ‘by design’. Of course, I can change the ‘rules’, but beamer has been around a long time and it’s also somewhat complex code. As such, I’m always having to make judgements on how to deal with these bugs. My advice: don’t use \subsubection in beamer documents! Certainly don’t be surprised if when you ignore that advice odd things happen.

Written by Joseph Wright

September 7th, 2013 at 5:03 pm

Posted in beamer

Customising TeXworks auto-completion

without comments

TeXworks is a very flexible editor, and one of the things you can customise, if you want, is the set of auto-completion values it knows. For those of you who are not familiar with it, TeXworks uses a simple list of simple completion options, so when I type

\doc

I can press the Tab key and be offered

\documentclass{}

and if I press Tab again,

\documentclass[]{}

That’s very useful, but some of the auto-complete options are not ones I use a lot. There are also a few inconsistencies in how the results are formatted: while TeXworks inherited a basic set from TeXShop, it also comes with some additions and they don’t always quite agree on how things should work! So I’ve been looking a bit at sorting out my own custom set, adding things I use, removing ones I don’t and so on.

The basic format for the auto-complete files is to have a first line for the encoding

%% !TEX encoding = UTF-8 Unicode

then one or more lines for each completion. Each line can either just have a completion vale

\alpha

or have a ‘shortcut’ text version

xa:=\alpha

There are then a few bits of ‘helper’ syntax. You can use #INS# to show where the cursor should end up, #RET for a return and as a marker you can jump to using Ctrl-Tab (Option-Tab on the Mac). So for example the \documentclass lines read

\documentclass{#INS#}#RET#
\documentclass[#INS#]{•}#RET#

I’m told that TeXShop has extended the syntax a bit, but at least at the moment in TeXworks that all there is to know.

So what have I done to customise the files? TeXworks comes with four auto-complete files, but the values offered simply come from them all together (you can’t currently select only some files). (You might wonder where these files live: they are ‘hidden away': TeXworks will tell you how to find them from Help -> Settings and resources.) So my first move was to create one new file, after first backing up the originals of course! I then did a few experiments, thinking about what I use a lot, what I’m used to, etc. I did wonder about some of the choices in the standard files, but a bit of experimentation suggests they are not so bad! So I’ve currently ended up mainly just adding a few things, for example

{tikzpicture}[#INS#]#RET#•#RET#\end{tikzpicture}•

for TikZ pictures and

cs:=\cs{#INS#}
pkg:=\pkg{#INS#}
\cs{#INS#}
\pkg{#INS#}

for package development work. I’m also not too keen on having too many of the ‘shortcut’ values, which don’t start \, so I’ve removed most of them and have just a core set (things like bf and em). If you want to see my current full set, you can of course download it.

So is there anything I’d like to see added to the way auto-complete works? I have a few ideas! From my questions on the TeXworks mailing list, I’ve picked up that TeXShop maintains indentation when doing auto-complete: TeXworks doesn’t, and I think it would be a good addition. TeXShop also allows an extended syntax

\documentclass[#INS#•#INS#]{•}#RET#
\rule[#INS#•‹lift›#INS#]{•‹width›}{•‹height›}

where you can always have a for ‘fill in’ and have ‘reminders’ about what the values are. That looks useful too.

Written by Joseph Wright

September 1st, 2013 at 9:45 am

Posted in TeXworks

TeX Live 2013 released

with one comment

Browsing the TeX Live site today, I see that TeX Live 2013 has been released. There are as usual a few changes to note. My highlights:

  • XeTeX now uses the HarfBuzz shaper rather than the older ICU engine (which is no longer being developed): see my earlier post about this change
  • LuaTeX is updated to Lua 5.2 (the latest Lua release)
  • Microtype now supports protrusion in XeTeX and LuaTeX

I’ve been using the pretest version of TeX Live for a while, and am very happy that all seems to be working just fine. Of course, many people will want the DVD version, which will be a while, but for the downloaders you can grab it now.

Written by Joseph Wright

June 18th, 2013 at 8:27 pm

Posted in General

Tagged with

A talk in Paris

with 3 comments

Yesterday I was in Paris, giving a talk to GUTenberg about LaTeX3 as part of their user meeting. The event was very well attended, and ‘official’ video recording will be available of all of the presentations. People seem very keen to hear talk I was giving, so I recorded the audio and have put it together with the slides as a video (thanks to UK-TUG for use of their Vimeo account!). I do hope it all makes sense!

Written by Joseph Wright

June 2nd, 2013 at 5:04 pm

Posted in LaTeX3

TeX Welt: A new (German) TeX blog

without comments

If you are involved in (La)TeX for any length of time, you notice that using TeX is very popular in German-speaking countries. DANTE, the German-speaking TeX user group, is big, and there are several German-language TeX websites out there. They’ve now been joined by a new German-language TeX blog, TeX Welt. This has popped-up following some discussion on the TeX-sx chat system, and is being hosted by Stefan Kottwitz (a man with a server farm in his house!). Of course, we don’t all speak fluent German, but I’ll certainly be keeping an eye on the new site: always more to learn!

Written by Joseph Wright

May 27th, 2013 at 7:27 pm

Posted in General

Keeping track of changes

without comments

Moving my code from BitBucket to GitHub has shown me (once again) the need to keep my changes to my code very organised. There was quite a bit of work to do getting all of the issues migrated, and it wasn’t helped by the fact that I’ve been less than perfect in keeping each commit I make focussed on one thing. A timely reminder that it’s important to be careful if you write a lot of code.

Written by Joseph Wright

May 25th, 2013 at 10:27 pm

Posted in General

Moving from Mercurial to Git

with 7 comments

Over the years of working with LaTeX, I’ve picked up a bit about version control systems for code: this post is more about general programming than TeX.

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.

Written by Joseph Wright

April 25th, 2013 at 9:08 am