#229 pgfpagesuselayout breaks beamer class

v1.0 (example)
closed-fixed
nobody
None
5
2014-08-15
2012-12-13
Anonymous
No

The following minimal example, which is similar to an example in your documentation

\documentclass{beamer}
\usepackage{pgfpages}
\pgfpagesuselayout{4 on 1}[letterpaper,landscape,border shrink=5mm]

\begin{document}
\begin{frame}
This text is shown on the upper left.
\end{frame}
\begin{frame}
This text is shown on the upper right.
\end{frame}
\begin{frame}
This text is shown on the lower left.
\end{frame}
\begin{frame}
This text is shown on the lower right.
\end{frame}
\end{document}

is broken when either of the latex->dvips->ps2pdf or latex->dvipdf compile routes is used. By broken I mean the {4 on 1} pagelayout feature does not work and here the pdf-file only contains the first frame. Using pdflatex does give a pdf-file with the {4 on 1} feature. Commenting out the "\pgfpagesuselayout" line does generate an appropriate beamer document regardless of the path to generate the pdf-file. It thus appears that pgfpagesuselayout breaks something in the beamer class when anything but pdflatex is used. This has been broken for sometime, although the documentation has not changed. At one time the non-pdflatex routes did generate appropriate {4 on 1} pdf-files.

Discussion

  • Till Tantau

    Till Tantau - 2013-07-16
    • status: open --> closed-fixed
    • Group: --> v1.0 (example)
     
  • Till Tantau

    Till Tantau - 2013-07-16

    Fixed in CVS. Hopefully, my rather fundamental changes did not break anything else in turn...

     
  • Christian Feuersänger

    Unfortunately, it did: image externalization is broken if used with latex/dvips (broken bounding box).

    Minimal example:

    \documentclass{article}

    \usepackage{tikz}

    \usetikzlibrary{external}
    \pgfkeyssetvalue{/tikz/external/system call}{%
    latex \tikzexternalcheckshellescape -halt-on-error -interaction=batchmode -jobname "\image" "\texsource" %
    && dvips -o "\image".ps "\image".dvi %
    }%

    \tikzexternalize[force remake]

    \begin{document}

    \begin{tikzpicture}
    \draw (0,0) grid (10,10);
    \end{tikzpicture}
    \end{document}

    It works if I undo

    \def\pgfsys@papersize#1#2{%
    \special{papersize=#1,#2}%
    }% \expandafter\gdef\expandafter\pgfsys@atbegindocument\expandafter{\pgfsys@atbegindocument\special{papersize=#1,#2}}}

     
  • Christian Feuersänger

    It also works if pgfsys@papersize does BOTH: the \special and \atbegindocument.

    It also works if I modify \def\pgf@externalend such that it calls \pgfsys@papersize twice, once at its old place (needed for pdftex and xelatex) and once where it invokes atbegindocument.

    But it seems as if the resulting pictures differ between pdftex and dvips.

     
  • Christian Feuersänger

    Ok, the differences in appearance seem to be independent of the externalization.

    Brief experiments with pgfsys@papersize did not indicate causes...

    Minimal example would be

    \documentclass{article}

    \usepackage{tikz}

    \begin{document}

    \begin{tikzpicture}
    \draw (0,0) grid (10,10);
    \end{tikzpicture}
    \end{document}

    ; the images appear to have different sizes when compiled with

    latex P && dvips -o P.ps P.dvi && ps2pdf14 P.ps P.pdf

    or

    pdflatex P

    I will file a bug report next week.

     
  • Christian Feuersänger

    I have fixed the regression in PGF CVS.

    My previous comment regarding different page sizes was a test issue: added 'a4paper' solved it (apparently, lua and dvips have different default page sizes).

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks