Compatbility issues with pdfpages

[PeterBetlem]

The following MWE illustrates issues with pdfpages:

\documentclass[]{article}

\usepackage{pdfpages}

\usepackage[dpi=200]{graphicscache}

\begin{document}
\includepdf[pages=-]{pdfs/FB.pdf}
\end{document}

With the following error repeating itself:

Missing number, treated as zero.
<to be read again> 
                   !
l.8 \includepdf[pages=-]{pdfs/KW.pdf}

/test.tex:8: Illegal unit of measure (pt inserted).
<to be read again> 
                   !
l.8 \includepdf[pages=-]{pdfs/KW.pdf}

/test.tex:8: Missing number, treated as zero.
<to be read again> 
                   !
l.8 \includepdf[pages=-]{pdfs/KW.pdf}

/test.tex:8: Illegal unit of measure (pt inserted).
<to be read again> 
                   !

Removal of the graphicscache package gets rid of the error and successfully includes the pdf files.

EDIT: Running:

This is LuaHBTeX, Version 1.16.0 (TeX Live 2023) system commands enabled.

[xqms]

Thanks for the report! Hm, I guess this has to do with the page=- option. Probably pdfpages uses \includegraphics internally. At the moment, I need to add all "extra" options that \includegraphics should support manually. At some point we need to find a more clever way... I'll see if adding the option helps.

[xqms]

It was due to pdfpages using the width=! and height=! options, which I did not handle correctly. Fixed in 6b6e718c3ea5f6d9f41ea65df2889bc430279c2e. The current master version should now work.

[PeterBetlem]

Thanks! I will give it a quick shot. I assume I should just use the master branch from here?

EDIT: I still see some issues; right now no more issues are raised by latex internally, but not full pdf documents are included. Instead, it seems I only manage to get the first page of each includedpdf file. I assume there won't be a quick fix to deal with the page=- or page={-} options?

[xqms]

Hmm, I have traced that problem down to my usage of the standalone class, which interferes with multi-page PDFs (it only produces a single output page). That seems hard to fix, but I will look further.

In the meantime, I assume that using \includegraphics[page=1]{my_pdf.pdf} (and manually incrementing page=N) is not an option for you?

[xqms]

Further details on the problem (the above is slightly wrong):

pdfpages calls \includegraphics to get the number of pages in the PDF. In the usual case, the resulting number of pages is saved by \includgraphics in a TeX variable. In our case with graphicscache, \includegraphics actually invokes a second LaTeX instance with the standalone class. Inside this LaTeX instance, the TeX variable is correctly set, but the resulting PDF file only contains one page. Now graphicscache will call \includegraphics for the resulting compressed PDF, which only has one page and thus the TeX variable is set to 1.

Options to fix this:

• Check \pdfpages@includegraphics@status to recognize that we are called by pdfpages in order to determine the page count. In that case, fall back to direct inclusion. This is somewhat unsatisfying, since it removes all effects of caching (=> slower speed, probably breaks release script).
• Somehow return the number of pages out of the sub-process. This is difficult, since all different TeX versions use different variables/counters (ugh).
• Let the sub-instance of LaTeX produce a PDF with the same number of pages. Likely to break other stuff (what if the user passes page=N?).
• Somehow tell pdfpages the number of pages in another way?

[xqms]

Somehow return the number of pages out of the sub-process. This is difficult, since all different TeX versions use different variables/counters (ugh).

Tried to do this, since it would be portable and would also fix other packages depending on page counts, but it didn't work out. At least in pdftex, \pdflastximagepages is read-only.

Check \pdfpages@includegraphics@status to recognize that we are called by pdfpages in order to determine the page count. In that case, fall back to direct inclusion. This is somewhat unsatisfying, since it removes all effects of caching (=> slower speed, probably breaks release script).

I guess this is the way forward. However, this only fixes the issue for newer LaTeX distributions (at least on Ubuntu 20.04 this flag is not yet present).

[xqms]

Implemented a fix in #25. @PeterBetlem If you have time, could you test if this fixes your problem?

[PeterBetlem]

I will give it a shot over the weekend and get back to you, thanks for looking into it!

[PeterBetlem]

It seems to work as expected! Great fix, thanks 👍

[xqms]

Thanks for the confirmation :)