Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

This question is very similar to this one. However, since the solution provided there cannot solve my problem, I figured that I'd post my specific problem.

Here is a minimal example to illustrate this issue:

\documentclass{beamer}
\setbeameroption{show notes}
\begin{document}
\begin{frame}<1-2>[label=myframe]{Frame Title}
  \note<1>{Some notes on the first point.}
  \note<2>{Some notes on the second point.}
  \begin{itemize}
  \item<alert@1> First point.
  \item<alert@2> Second point.
  \item<alert@3> Third point. %optional
  \end{itemize}
\end{frame}
\appendix
\begin{frame}{Appendix}
  Some more elaboration.
\end{frame}
\againframe<3>{myframe}
\end{document}

This example is compilable, but LaTeX tells me there are multiply defined labels. The labels in question are myframe, myframe<1> and myframe<2>. I conjecture this is due to the fact that when a note page is created, the note page also "inherits" the label of the main frame, thus creating such problem. If so, I guess we could somehow patch the note page mechanism in beamer such that LaTeX would stop emit such warnings.

Anyone has any solutions?

share|improve this question
    
Just an observation rather than anything helpful: the \againframe does not appear to responsible for the duplicated labels here; commenting it out does not change the behaviour, but leaving it in and commenting out the \setbeameroption{show notes} removes the warnings. –  cyberSingularity Nov 5 '12 at 23:58
    
@cyberSingularity That's right. Thanks for the observation. I have modified the title so that it doesn't mention \againframe. I always thought one main reason for using labels is to use \againframe. –  kccqzy Nov 6 '12 at 2:33
    
Working intensely with beamer I have got so many "multiply defined labels" warnings that I somehow got used to them. I have, however, never experienced any particular problem with them as they tend to end up on the same page. So besides compiler output aesthetics: Is there a concrete issue? –  Daniel Nov 6 '12 at 8:05
    
As far as I understand, this is not really as simple as being a bug in beamer. I will attempt to explain more later, showing the results of my diagnosis, and hopefully offer a potential fix, or at least the beginnings of one. (Please don't close the question in the meantime!) @Daniel: Multiply defined labels can be an issue, depending on how you are later referring to those labels. Again, I'll try to explain more later. –  cyberSingularity Nov 6 '12 at 10:12
    
@Daniel: If you are used to all kind of warnings in beamer, I suspect texblog.net/latex-archive/presentations/beamer-warnings could help. Regarding your specific problem, I cannot help :-( –  Svend Tveskæg Nov 6 '12 at 18:42

1 Answer 1

up vote 5 down vote accepted

Understanding why the problem occurs and how to potentially fix it is a bit TeXnical I'm afraid.

Diagnosing causes of the problem:

  • Disabling notes eliminates the issue.
  • Redefining \insertslideintonotes to do nothing eliminates the issue: \renewcommand{\insertslideintonotes}[1]{}.
  • Using any form of \label (even \label<1>) in a slide with notes causes the issue, not just using the label=name option to frames (the latter internally uses \label anyway).

  • Implementation of \insertslideintonotes in beamer:

    beamer puts the contents of each slide into a box register called \beamer@framebox, and copies the box register into \beamer@frameboxcopy. The latter is used for the mini version of the slide shown in the notes pages (via \insertslideintonotes). Label commands are also stored in those boxes in the form of 'whatsit' \write nodes, and so are written again when the box is copied.

Why multiply defined labels can be problematic:

  • Multiply defined labels are not always consistent. The default behaviour in LaTeX is to use the last defined label, rather than ignoring later redefinitions of the same label. This is not the desired behaviour in the case of beamer because the label will then refer to notes slides instead of the main slide (as notes slides always come after the main slide). The following example illustrates this (the reference in the last frame is wrong):

    \documentclass{beamer}
    \setbeameroption{show notes}
    
    \begin{document}
    
    \begin{frame}<1-2>[label=myframe]{Frame Title}
      \note<1>{Some notes on the first point.}
      \note<2>{Some notes on the second point.}
      \begin{itemize}
      \item<alert@1> First point.
      \item<alert@2> Second point.
      \item<alert@3> Third point. %optional
      \end{itemize}
    \end{frame}
    \appendix
    \begin{frame}{Appendix}
      Some more elaboration.
    
      I think \texttt{myframe} starts on page \getpagerefnumber{myframe}.
    \end{frame}
    \end{document}
    

Solutions

  • I asked a question about removing or deactivating such nodes in this question, and Stephan Lehmke's solution led me to the following patch. The idea is that by editing the box to use \leaders, TeX will ignore the \write whatsits. I will try to get the beamer maintainers to consider it for inclusion in the beamer core:

    Patch code:

    \usepackage{etoolbox}
    \makeatletter
    \patchcmd\beamer@framenotesend{\global\setbox\beamer@frameboxcopy=\copy\beamer@framebox}{%
    \global\setbox\beamer@frameboxcopy=\copy\beamer@framebox
    \global\setbox\beamer@frameboxcopy=\hbox{\leaders\copy\beamer@frameboxcopy\hskip\wd\beamer@frameboxcopy}%from Stephan Lehmke's comment on http://tex.stackexchange.com/q/82250/17427
    }{}{\showtokens{failed to patch \beamer@framenotesend}}
    \makeatother
    

    Patched MWE (note that the pdfTeX warning (dest) messages are another outstanding issue in beamer):

    \documentclass{beamer}
    \setbeameroption{show notes}
    
    \usepackage{etoolbox}
    \makeatletter
    \patchcmd\beamer@framenotesend{\global\setbox\beamer@frameboxcopy=\copy\beamer@framebox}{%
    \global\setbox\beamer@frameboxcopy=\copy\beamer@framebox
    \global\setbox\beamer@frameboxcopy=\hbox{\leaders\copy\beamer@frameboxcopy\hskip\wd\beamer@frameboxcopy}%from Stephan Lehmke's comment on http://tex.stackexchange.com/q/82250/17427
    }{}{\showtokens{failed to patch \beamer@framenotesend}}
    \makeatother
    
    \begin{document}
    
    \begin{frame}<1-2>[label=myframe]{Frame Title}
      \note<1>{Some notes on the first point.}
      \note<2>{Some notes on the second point.}
      \begin{itemize}
      \item<alert@1> First point.
      \item<alert@2> Second point.
      \item<alert@3> Third point. %optional
      \end{itemize}
    \end{frame}
    \appendix
    \begin{frame}{Appendix}
      Some more elaboration.
    
      I think \texttt{myframe} starts on page \getpagerefnumber{myframe}.
    \end{frame}
    \againframe<3>{myframe}
    \end{document}
    
  • The alternative implementation that beamer could take would be to reprocess the content of the whole frame again when calling \insertslideintonotes, but which might have other unwanted side-effects in some circumstances, and so this should only be provided as an option to people who know what they are doing, instead of changing default behaviour! I don't think this would be an easy job either.

  • You could also use the following patch in the preamble to only save the first \label, and hope everything will be alright.

    % keep only the first definition of a given label, in contrast to the default LaTeX behaviour (and compile twice to see the difference!)
    \makeatletter
    \def\@newl@bel#1#2#3{{%
      \@ifundefined{#1@#2}%
        {\global\@namedef{#1@#2}{#3}}% moved this line from always being executed into the 'true' case for \@ifundefined.
        {\gdef \@multiplelabels {%
           \@latex@warning@no@line{There were multiply-defined labels. Later redefinitions were ignored}}%
         \@latex@warning@no@line{Label `#2' multiply defined. Ignoring later redefinitions}}%
      }}
    \makeatother
    
share|improve this answer
2  
+1 for investigations! –  Daniel Nov 7 '12 at 8:26
    
Now reported at bitbucket.org/rivanvx/beamer/issue/226/… –  cyberSingularity Nov 18 '12 at 20:27
    
...and already fixed using the \leaders suggestion, should be included in the next beamer release. –  cyberSingularity Nov 18 '12 at 20:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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