6

I have a presentation with about 50 slides and a lot of PgfPlots which take long to compile. I tried to use \includeonlyframes{} with the result that only the selected frame is in the resulting PDF but that compilation just takes as long as before. From the log file I can see that still everything seems to be compiled: all SVG images are converted to PDFs and I see PgfPlots log messages for all my plots.

Update

The problem only occurs if not all frames that include images have a label. Please consider the following MWE (compile with xelatex mwe.tex):

\documentclass{beamer}
\includeonlyframes{ex1}
\begin{document}
    \frame{
        Whether this frame has a label or not, seems to be irrelevant.
        \typeout{No, the graphic does not matter}
    }
    \frame[label=ex1]{
        This frame should have a label.
        \includegraphics{example-image-a}
    }
    \frame[label=ex2]{
        This frame should also have a label.
        \includegraphics{example-image-b}
    }
\end{document}

This behaves as expected: only the second frame is in the output PDF and the log file mentions only the inclusion of example-image-a. Now remove the label ex2 from the third frame:

\documentclass{beamer}
\includeonlyframes{ex1}
\begin{document}
    \frame{
        Whether this frame has a label or not, seems to be irrelevant.
        \typeout{it is relevant, it just does not show in the log file}
    }
    \frame[label=ex1]{
        This frame should have a label.
        \includegraphics{example-image-a}
    }
    \frame{
        This frame should also have a label.
        \includegraphics{example-image-b}
    }
\end{document}

Beamer now behaves differently: it seems like all frames are compiled (at least those with images) but the PDF still contains only the second frame. Here's a snippet from the log:

File: example-image-a.pdf Graphic file (type QTm)

<use  "example-image-a.pdf" >

LaTeX Font Warning: Font shape `OT1/cmss/m/n' in size <4> not available
(Font)              size <5> substituted on input line 10.

[1

]
File: example-image-b.pdf Graphic file (type QTm)
 <use  "example-image-b.pdf" >

When compiling the first MWE, example-image-b.pdf is not mentioned.

In my original document I use a lot of PDF and PgfPlots inputs, but I have only used one label. The consquence was that all frames got compiled despite defining only one frame with \includeonlyframes{}. The weird thing is, that it seems to be irrelevant whether plain frames without images have a label or not (see the first frame in the MWE).

So either I'm totally misunderstanding the Beamer doc or this is a bug. What do you think?

Deve
  • 604
  • 1
    this does seem to contradict the beamer documentation (section 4.3.3), so an inquiry to the maintainer(s) would seem to be in order. for that purpose, a minimal example with only two frames, and only one included, and the log showing that both are in fact compiled, would seen adequate. – barbara beeton Aug 18 '16 at 17:53
  • @barbarabeeton Good idea, thank you for your comment. – Deve Aug 18 '16 at 18:08
  • @Deve Have you considered asking Joseph Wright if this intended behaviour? You can find him in the chatroom http://chat.stackexchange.com/rooms/41 – samcarter_is_at_topanswers.xyz Aug 22 '16 at 11:10
  • 4
    I'm voting to close this question as it's status by design, see http://chat.stackexchange.com/transcript/message/31881278#31881278 – samcarter_is_at_topanswers.xyz Aug 24 '16 at 18:47
  • @samcarter I still don't understand what "status by design" is supposed to mean. Is it intended? Is it too hard to be implemented differently? It's hard to believe that the behaviour of \includeonlyframes should intentionally depend on whether graphics are inlcuded or not. All this could be explained in answer to this question. – Deve Aug 24 '16 at 20:04
  • "Status by design" means that this is intended to work like this and no bug. \includeonlyframes does not depend on whether or not there are graphics, but if the frames have a label or not. I only used graphics for the MWE because they produce some typeout in the log file. – samcarter_is_at_topanswers.xyz Aug 24 '16 at 22:28
  • @samcarter Yes, it does. Please see my MWE: You have to put a label on all frames including graphics to achieve the exclusive effect while it is irrelevant whether frames without graphics have a label. – Deve Aug 25 '16 at 05:12
  • @Deve No it does not :) The first frame just had nothing to write in the log. Try with the line I added to you example. – samcarter_is_at_topanswers.xyz Aug 25 '16 at 08:41
  • @samcarter Presentation slides with images is quite a common thing. The second code example and its log file clearly prove that the 3rd frame with \includegraphics is processed, although not mentioned in the list of \includeonlyframes{...}. This cannot be intended behaviour. To me, the question is fully legitimate. – AlexG Aug 25 '16 at 09:01
  • 1
    @AlexG All frames which don't have a label that is not in the list of \includeonlyframes{...} are processed, also ones without images (try the example with \typeout{No, the graphic does not matter}). Feel free to vote for reopening. – samcarter_is_at_topanswers.xyz Aug 25 '16 at 09:17
  • 1
    Vaguely related: http://tex.stackexchange.com/a/52904/86 (in particular, note what I say in the 3rd paragraph about TeX still compiling the whole document). You may be better off looking at the TikZ externalisation library to solve the issue with recompiling the graphics every time. – Andrew Stacey Aug 25 '16 at 09:23
  • 2
    It may be status-by-design for \includeonlyframes but there's a sensible question here. Why don't you rephrase the question to ask how to limit beamers attention to just one frame, completely ignoring all others? Or how to optimise your compilation so that you aren't compiling every plot every time. (Mind you, there are probably other questions on those themes that this might then be a duplicate of, but that would depend on how you rephrase it.) – Andrew Stacey Aug 25 '16 at 09:50
  • 1
    If you rewrite it, flag it for moderator attention to ask for it to be reopened (even if it's reclosed as a duplicate, that's still a better solution than the current "off topic" status). I would support reopening under those circumstances - but as it's been put on hold, it's best to improve it before asking for it to be reopened. – Andrew Stacey Aug 25 '16 at 09:52
  • A rephrased question on "how to fix or workaround" would certainly be valuable for future readers! – samcarter_is_at_topanswers.xyz Aug 25 '16 at 12:28
  • @samcarter You convinced me with your edit. Thanks for your patience! – Deve Aug 25 '16 at 18:33

0 Answers0