4

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.

2
  • Not an expert with pdfx. Try with \usepackage[luatex]{pdflscape} and see whether all works.
    – egreg
    Dec 26, 2017 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. Dec 27, 2017 at 1:03

3 Answers 3

4

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.

7
  • Thank you. The authors of the package should look into it. Hopefully a patch will be distributed soon.
    – Rupert
    Dec 27, 2017 at 9:36
  • @Rupert you could report it to them.... Dec 27, 2017 at 10:37
  • Done. They may join us in this thread.
    – Rupert
    Dec 27, 2017 at 18:42
  • 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.
    – Ross Moore
    Dec 27, 2017 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, 2017 at 23:32
5

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.

2
  • 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, 2017 at 17:42
  • see my comment above.
    – Ross Moore
    Dec 27, 2017 at 23:07
0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .