# Is pdflscape compatible with pdfx?

The following code triggers an error when using pdflscape.

\documentclass{letter}
\usepackage[a-1b]{pdfx}
%\usepackage{pdflscape} % breaks things
\begin{document}
Hello World
\begin{landscape}Hello from down under\end{landscape}
\end{document}


The error is:

150: Package pdflscape Error: Neither pdfTeX, PostScript, nor dvipdfm driver found.

See the pdflscape package documentation for explanation.
Type  H <return>  for immediate help.
...

l.150   }\@ehc

319 words of node memory still in use:


This holds with lualatex/texlive 2017.

EDIT

The followig test shows exactly the same problem, but the proposed solution is not applicable.

\documentclass{letter}
\usepackage[a-1b]{pdfx}
\usepackage[final]{pdfpages}
\begin{document}
Hello World
\end{document}


In this case, pdfpages triggers the pdflscape error. The problem sits in the pdfpages source code, where pdflscape.sty is loaded. It is a bug.

• Not an expert with pdfx. Try with \usepackage[luatex]{pdflscape} and see whether all works. – egreg Dec 26 '17 at 16:08
• while the bug is in pdfx package as I show in my answer, @egreg's workaround is equally applicable to your second example, just add the line that he shows before you load pdfx. – David Carlisle Dec 27 '17 at 1:03

This is a bug in pdfx.sty the code

%%----------------------------------------------------------------------
\ifxetex
% override the \ifpdf check
\pdftrue
\else\ifluatex
\pdftrue
\fi\fi
\RequirePackage{xmpincl}
\ifxetex
% revert \ifpdf
\pdffalse
\else\ifluatex
\pdffalse
\fi\fi


sets \ifpdf to false for luatex which is wrong and breaks any later packages that are testing for pdf output.

%%----------------------------------------------------------------------
\ifxetex
% override the \ifpdf check
\pdftrue
\else\ifluatex
\pdftrue
\fi\fi
\RequirePackage{xmpincl}
\ifxetex
% revert \ifpdf
\pdffalse
\else\ifluatex
%\pdffalse
\pdftrue
\fi\fi


is a simple fix although forcing it to use \pdftrue isn't correct either if you want to support dvilualatex the correct value is set by the ifpdf package, but it isn't clear what is the intention of this code section so here I just suggest the simple fix of setting the value to true for luatex.

• Thank you. The authors of the package should look into it. Hopefully a patch will be distributed soon. – Rupert Dec 27 '17 at 9:36
• @Rupert you could report it to them.... – David Carlisle Dec 27 '17 at 10:37
• A better fix is: \newif\ifpdfx@pdfcheck \ifpdf \pdfx@pdfchecktrue \else \pdfx@pdfchecktrue \fi \pdftrue \RequirePackage{xmpincl} \ifpdfx@pdfcheck \pdftrue\else\pdffalse\fi  which reverts to the value of \ifpdf after temporarily changing it to load the xmpincl package. – ozross-RRM Dec 27 '17 at 23:03
• Interesting, I used some of the pdfx code for my own rendition in novel class, but since only LuaLaTeX is permitted, driver-specific problems don't show. Neither do PDF/A problems, since only PDF/X is supported. I did notice some oddities in the pdfx package (not duplicated in my own code), but they are unrelated to the issue here. – user139954 Dec 27 '17 at 23:32

If you load pdflscape before pdfx there is no error.

On the other hand, the documentation of pdfx recommends to load it first; in this case do

\usepackage[luatex]{pdflscape}


Apparently pdfx sets something that make it impossible to pdflscape to correctly guess the used engine, when it is LuaLaTeX.

• pdfx uses \immediate\write to place information in the PDF, then later writes PDFInfo, which must agree. If the necessary information (which includes layout, title) is not available at the time pdfx is loaded, there will be an error, although the message may be obscure. If any of the necessary information is changed after pdfx is loaded (such as by \newgeometry) then pdfx might not notice the problem, but the PDF will definitely be non-compliant, even if compile succeeds. My own modification of pdfx, part of novel class, auto-loads when changes can no longer be made. – user139954 Dec 26 '17 at 17:42
• see my comment above. – ozross-RRM Dec 27 '17 at 23:07

There may still be problems with LuaLaTeX and pdfx.sty, since primitives were changed. For example, the XMP Metadata may not be uncompressed. There's an easy fix for this too.

Within pdfx.sty use the following code quite early:

\let\real@lua@pdfobj\pdfobj \def\pdfobj{\immediate\real@lua@pdfobj uncompressed }%

then \let\pdfobj\real@lua@pdfobj after the XMP packet has been written. You could use these lines (surrounded by \makeatletter ... \makeatother within the preamble, surrounding \usepackage{pdfx}.