4

I did a beamer presentation recently and was annoyed by

  1. The increase in file size when the handout option is not given.
  2. The increase in time it took to run pdflatex

I think these two problems are related. While I agree that some increase in both file size and compile time is necessary, the below experiment shows that something is going wrong. Effectively, the resulting pdf files contain the exact same content.

As a demonstration I create n beamer blocks containing a small picture. This has about the effect of having logos in the heading (they are included on every slide). EDIT: as pointed out, blocks are different in that they require costly rendering options.

What can be done to overcome this inconvenient problem?


handout option, boadilla theme (1 page):

  • compile time (user): 1.6s
  • file size: 38369 KiB

no handout option, boadilla theme (50 pages)

  • compile time (user): 1.183m !!
  • file size: 230133 KiB

no handout option, default theme (50 pages)

  • compile time (user): 5.6s
  • file size: 136877 KiB

no handout option, no blocks (50 pages) (instead using \pause)

  • compile time (user): 3.3s (boadilla, default theme 2.9s)
  • file size: 101033 KiB

Additional note:

included image has size 2815 KiB. This may account for 140750 KiB or 61.2 % of the no handout file size if included separately. But apprently, this should not be done.

This is the minimal example:

\documentclass[]{beamer} % pdflatex runs longer, resulting in a much larger file
%\documentclass[handout]{beamer}
\usepackage{lmodern}% http://ctan.org/pkg/lm
\usepackage{pgffor}
\mode<presentation>
\usetheme{Boadilla} % this seems to be the main bottle neck. Shadings and rounded corners 
\author[se]{sebastian}
\title[atitle]{A title}

\begin{document}
\def\nitems{50}
\begin{frame}
  \foreach \i in {1,...,\nitems}
  {
  \begin{block}{t\i}<\i-> % blocks require a lot of processing time
    \includegraphics[height=1mm]{2815-kb.pdf}
  \end{block}
  }
\end{frame}
\end{document}

Note: The file 2815-kb.pdf does not contain any bitmap.

  • does your pdf include bitmap? – percusse Nov 8 '13 at 15:33
  • 3
    Did you try with another theme (default theme for example) or without block? The results may surprise. – Paul Gaborit Nov 8 '13 at 15:49
  • 1
    @PaulGaborit. Very interesting remark! 5.77s and 136591 KiB. Can you explain the reason for this? – Sebastian Nov 8 '13 at 15:51
  • "Effectively, the resulting pdf files contain the exact same content": Maybe you could explain that in a some more datail, given that in handout mode we end up with just one page, while in beamer mode, we ends up with 50 pages (which, of course, is well explainable by the fact that handout mode collapses all steps of a frame's animation into a single slide.) – Daniel Nov 8 '13 at 21:29
  • @Daniel I'm referring to the fact that although there are more pages, there is not more content. It is just spread on more pages. More pages should take little more file size or processing time given that the content is reused (as claimed by includegraphics). thanks also for your answer, I'll check tomorrow. – Sebastian Nov 8 '13 at 22:16
6

I think we have a misconception here regarding "the exact same content":

  • In handout mode, beamer collapses all steps of an overlay series into one, which in most cases means that only the last slide of a frame is shipped out. In your case, this results in a single-page PDF containing 50 beamer blocks (even though only eight of them are actually visible).

  • In presentation mode (default), beamer ships out one page per animation step, which results in a series of 50 PDF pages containing 1, 2, ..., 50 beamer blocks. So the resulting PDF contains 1+2+...+50=1275 beamer blocks.

As you have pointed out, the included graphics should not cause much of an overhead, as the graphicx package automatically makes sure that the content of a graphics object is embedded only once inside the PDF, that is, there is one image and 50 vs 1275 references to it.

However, even though part of the content is reused: Each beamer block still makes up at least one distinct object in the resulting PDF file, so your presentation version contains 25.5 times more PDF objects than the handout version.

This also explains the observation by Paul that the size difference depends a lot on the employed beamer theme and if one uses beamer blocks or not: The Bodialla theme uses rounded beamer blocks with a color transition between headline and body and a soft shadow. Apparently, this has quite an impact. If you add the following line to your example (after loading the theme):

\setbeamertemplate{blocks}[rounded][shadow=false]

the blocks no longer have a shadow and the size of the beamer version drops by 38 KiB (from 230361 to 192676), whereas the size of the handout version drops by only 2 KiB.

Disabling also the soft transition effect between the headline and the body of the block with

\makeatletter
\pgfdeclareverticalshading[lower.bg,upper.bg]{bmb@transition}{200cm}{ color(0pt)=(lower.bg); color(4pt)=(lower.bg); color(4pt)=(upper.bg)}
\makeatother

decreases the size further by an additional 8 KiB in the beamer version (to 192668).

My suspicion is that shadings have a relatively high cost per instance and that this just accumulates over the 1275 beamer blocks you have.

  • I think you and @PaulGaborit are right. The run-time/file size penalty comes from the decoration of the blocks (see my updated metrics). This isn't dealt in an efficient manner. For me, I'll do all the TeXing with the default theme now, and only switch in the end. That's slightly inconvenient, but okay. – Sebastian Nov 11 '13 at 12:24
  • your two suggestions bring down compile time to 32.2s. – Sebastian Nov 11 '13 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.