# Is it geometry or pgfpages bug?

With \usepackage[showframe]{geometry} inserted in 2 on 1 pgfpages layout produce an unexpected result. I have updated latex last week, before that this problem did not appear

\documentclass{article}
\usepackage{lipsum}
\usepackage[showframe]{geometry}
\usepackage{pgfpages}

\pgfpagesuselayout{2 on 1}[a4paper,border shrink=5mm,landscape]

\begin{document}

\lipsum[1-5]

\newpage

\lipsum[1-5]

\end{document}


This is how it looked like before the update.

• and what do you expect instead? Oct 27, 2020 at 20:52
• @SalimBou I took the liberty of adding the output one gets with TeX Live 2019. I guess that the problem is with pgfpages. Oct 27, 2020 at 21:05
• @egreg I guess the problem is with the latest LaTeX release breaking tons of third-party packages. Oct 27, 2020 at 21:12
• @HenriMenke I disagree. Unfortunately PGF is known to break things when hooking in \shipout using nonstandard methods. Oct 27, 2020 at 21:15
• @HenriMenke it is not breaking tons of packages, but if you want to get to cleaner interfaces then yes, those packages that had to work around issues in the past may have to adjust to the new existing interfaces and the no longer existing internals they overwrote. But given that adding the hook management was a huge step (and improvement toards standard handling) I would claim we managed quite will in getting it off without breakage -- on the whole. Oct 29, 2020 at 10:46

The issue has been temporarily resolved by adding a fix to firstaid (as part of the LaTeX format). This has been send off to CTAN so it should reach the major distributions today or tomorrow and from that point onwards should work again as before.

As @AndrewStacey observed the kernel needs to provide an interface to take over control at the very end of building up a page just prior to shipping it out to the dvi/pdf file as an applications like pgfmorepages want to add further control on what happens at this stage (instead of simply shipping the page out).

However, this can't be done through a "hook" of the new hook management as this is not about adding additional code (where several packages could add code and the only question to resolve is in what order) but it is about changing the process and only one process can be executed.

The model here has to be one where one process can be swapped in for another but only one process is ever active. My tentative term for that is that of a "configuration point" and we are currently working on iron out the interfaces and concepts for that. Once that is available we will work with package maintainers how to apply them and then take out the current "firstaid".

• Thanks for quick fix, I have updated firstaid and everything is fine. Oct 31, 2020 at 13:18

This is not an answer, it is a description of the problem. I am assured that this will be addressed soon in a proper manner.

The way that pgfpages (and its extension, pgfmorepages - which I maintain) works is by saying to LaTeX, "You build the entire page exactly how you want to, then just before you ship it out, I'll take it and squirrel it away for later consideration.". Then at a later point, they say "Right, now I want you to ship out exactly this page.".

From that description, it is hopefully clear that pgf[more]pages needs to interrupt the shipout routine at the very, very last moment. The page needs to be complete, including headers and footers, and backgrounds, and borders.

From poking around in the latex.ltx code, I can see that the LaTeX team have been working behind the scenes to streamline the LaTeX core. Part of that involves putting hooks at various points to allow packages to hook in to various routines in a more orderly fashion than has been previously possible. I guess that the purpose of this is to sort out the mess that is conflicting packages who all try to redefine the same command, environment, or routine.

With regard to the shipout routine, therefore, the new LaTeX kernel adds in its own code at the point of shipping out a new page which provides access to all of these hooks. One of which, by the way, is used by geometry to put the frame around the page (geometry doesn't know this - thanks to the wizardry of the LaTeX team an awful lot of packages should just work without modification).

So at the moment we have a race condition in that both LaTeX and pgf[more]pages are trying to insert their code into the shipout routine and both work by replacing \shipout by their code. The order that should happen is that LaTeX's code works first and then pgf[more]pages second. Unfortunately, as LaTeX is loaded before pgf[more]pages, actually what happens is that pgf[more]pages is executed first and then the LaTeX code. This means that code such as geometry's showframes is only executed when the page is actually shipped out and not when pgf[more]pages stores the page. This is why the frames are incorrect.

What appears to be needed is a "Right before shipout" hook that allows pgf[more]pages to swoop in at the last minute. That currently doesn't exist, however from comments from the LaTeX team it would appear that they are aware of the issue and will address it shortly.

• Thanks @AndrewStacey for this very detailed answer. Oct 28, 2020 at 20:57
• We will add a similar correction to the firstaid package. Please do not spread this advice around. If such code is added more than once people will end in loops (such as one gets if one loads both pgfpages and pgfmorepages). Oct 29, 2020 at 9:51
• what's this remark about the 18th centry supposed to mean? care to elaborate Andrew? As Ulrike said we will resolve your race condition in a day or two (CTAN distribution permitting). Mid-term we will provide an orderly way to extend the page building logic in a reliable manner (just like the hooks already do for other parts) without the need to low-level alter primitives or internal macros. Oct 29, 2020 at 10:04
• Sorry @FrankMittelbach, that was meant as a joke that clearly misfired. I've removed it. The timeline of the resolution wasn't clear to me from the comments to the question so I thought I'd dig into it to see what was going on. I hoped my comment at the outset made it clear that I didn't view this as a solution, just a temporary fix while a proper solution was figured out. Oct 29, 2020 at 10:22
• @dedded Andrew is a limey. (Apparently some consider that term derogatory; it is not intended that way. I know the bloke in question, and he's a nice kind of person.) Oct 30, 2020 at 12:03