# Adjust some pages' height to that of their contents

A document I am working on has two kinds of pages: title pages and content pages. For the digital version, it would be preferable if content were typeset in single, continuous pages. These pages' height would have to be computed from that of the content, and I'm having trouble achieving that.

Here's an example:

\documentclass{article}

\usepackage{lipsum}

\newsavebox\stagingbox
\newenvironment{content}
{%
\begin{lrbox}{\stagingbox}%
\begin{minipage}{\textwidth}%
}
{%
\end{minipage}%
\end{lrbox}%
%
% \textheight is theoretically just the total height of the box
\textheight=0pt\relax%
%
% \paperheight is made up of the various margins and distances
% of the class' page layout parameters plus \textheight
\paperheight=0pt\relax%
%
\pdfpageheight=\paperheight\relax%
%
\noindent%
\usebox{\stagingbox}%
\newpage%
}

\parindent=0pt\relax

\begin{document}%
Page with default size.%
\newpage%
\begin{content}%
Page with height adjusted to content. Following pages' height should also be adjusted to their content.%
\end{content}%
\begin{content}%
\lipsum[1]%
\end{content}%
\begin{content}%
\lipsum%
\end{content}%
Another page with default size.%
\end{document}


LuaTeX 1.0.4 reports a couple overfull vboxes, as though I had forgotten something in the computation. The pages also seem cropped in the output. What am I missing here?

I am aware of another approach which involves hooking into \shipout and using \pagetotal to get the page's width. Unfortunately, I haven't been able to get it to work just for some pages (as opposed to for the whole document). On the topic:

I've tried \AtNextShipout and even messed with the output routine to no avail.

• – John Kormylo Jun 28 '17 at 0:10
• @JohnKormylo Thank you, I had overseen that. Although standalone indeed seems to work, I would prefer a solution not based upon it, because its purpose isn't really my goal. Am currently skimming through the code to see if I can extract the bits useful to me. – Kalrish Jun 28 '17 at 0:58
• Also related: tex.stackexchange.com/questions/40911/… – John Kormylo Jun 28 '17 at 12:09
• Bonus for plural possessive of page, as pages'. – user139954 Oct 28 '17 at 1:53

Although I cannot answer your question "the TeX way," I believe I can provide helpful information that may guide you to a solution.

Your question pertains to a digital version, which (I assume) means that the document PDF will be viewed on a monitor, not printed to paper. If it is to be printed to paper (especially if commercial printer), then the following advice should be ignored.

In PDF technology, the "MediaBox" refers to the entire size of a page, whether or not all parts of it are printed. In fact, especially in commercial applications, portions of the pages are often not printed, or are printed but then cut away, so that the end user does not see them. TeX calls this the "paper size". Every PDF has it.

When printed to paper, the final (cut) size is the "TrimBox."

When viewed on a monitor, using compatible software, the visible portion is the "CropBox."

The boxes are nested: MediaBox >= CropBox >= TrimBox. Often, the CropBox is exactly the same as the MediaBox. Then, CropBox is not required. If the TrimBox is the same size, it is not required (except with PDF/X, where it is always required).

In your case, the relevant box is the CropBox. So, what you want to do is ensure that the CropBox is changed on a per-page basis. You do not have to change the MediaBox on a per-page basis.

Most TeX compilers simply set the MediaBox, CropBox, and TrimBox to be all the same. Generally, only the MediaBox is set, and the rest are equal by default. Using LuaLaTeX (and probably pdflatex) it is possible to set the CropBox and TrimBox at size different from MediaBox. However, I have only done this globally. I do not know if it works when the CropBox is changed on a per-page basis. I believe it does work, although the necessary code may not be available directly within TeX.

Experiment: Create a PDF of a few pages. Compile it without PDF compression, so that you can easily understand the PDF code in a hex editor. That is, \pdfcompresslevel=0 in Preamble. Open the PDF in a hex editor, and look for CropBox for each page. There will be four numbers, representing the XY coordinates of the lower left and upper right of the monitor-visible page (measured in Postscript points). Edit a CropBox. Then, take a look at the edited PDF. You might also play with the MediaBox entries, but this might be more of a problem.

I know that Adobe Reader, and some others, honor the CropBox. It may be that some PDF readers ignore it, and always use the MediaBox.

If the experiment works, and if your document is not too long, then you have the option of editing it, as described above. Obviously not suited to a document that will have its contents frequently revised.

Be sure to test the edited PDF using Adobe Reader. This software will complain about errors that some other PDF readers ignore. If an edited PDF can be seen in other readers but not Adobe Reader, then the pdftk software might be able to fix it.

EDIT: If your PDF does not already have CropBox information, see the accepted answer to this question, for how to add it: How to use macro inside \pdfpageattr However, in the \pdfpageattr command, ONLY use the line with CropBox. MediaBox is automatically added, and you do not need TrimBox or BleedBox.

After much tinkering, I managed to get it working and abstracted the functionality in the aphtc package. Its usage:

\documentclass{article}

\usepackage{aphtc}
\usepackage{lipsum}

\begin{document}%
Page with default height.%
Page with height adjusted to content. Following pages' height should also be adjusted to their content.%
\newpage%
\lipsum[1]%
\newpage%
\lipsum%