#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 - 2013-07-16
• status: open --> closed-fixed
• Group: --> v1.0 (example)

• Till Tantau - 2013-07-16

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

• 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}}}

• 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.

• 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.

• 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).