luatex85: New definition of \pdfcreationdate is problematic

Question

The package "datetime2" scanned the macro \pdfcreationdate. This failed with the changed definition in "luatex85.sty" and LuaTeX 0.95. See the following example:

\listfiles
\setcounter{errorcontextlines}{100}
\documentclass{article}
\usepackage{luatex85}
%\edef\pdfcreationdate{\pdfcreationdate}
\usepackage{datetime2}
\begin{document}
  \DTMnow
\end{document}

After uncommenting the edef line the problem is solved.

Since you have some responses below that seem to answer your question, please consider marking one of them as ‘Accepted’ by clicking on the tickmark below their vote count (see How do you accept an answer?). This shows which answer helped you most, and it assigns reputation points to the author of the answer (and to you!). It's part of this site's idea to identify good questions and answers through upvotes and acceptance of answers. — Martin Schröder, Jun 05 '16 at 21:20

score 12 · Answer 1 · answered Apr 30 '16 at 17:31

It's a tough problem, unfortunately. The developers of LuaTeX decided to remove several primitives favoring a syntax

\pdffeedback <keyword>

Some of the removed primitives were expandable:

\pdftexrevision
\pdfxformname
\pdfcreationdate
\pdffontname
\pdffontobjnum
\pdffontsize
\pdfpageref
\pdfcolorstackinit

which means that one expansion step was sufficient for them to deliver their expansion. Note that one expansion step is sufficient also now provided

\pdffeedback creationdate

is used. The luatex85 package provides the old names around the new syntax, doing

\def\pdfcreationdate{\pdffeedback creationdate}

but this means that two expansion steps are needed and this is where datetime2 fails because it does

\expandafter\@dtm@parsepdfdatetime\pdfcreationdate\@dtm@endparsepdfdatetime

The workaround you use is good, in the particular case, because \pdfcreationdate in pdftex is “fixed” and doesn't change once set. So luatex85 might indeed do \edef\pdfcreationdate{\pdffeedback creationdate}. However this wouldn't work with other old primitives such as \pdffontsize, because this requires an argument (a font specifier).

The packages using those primitives should be updated to do two expansion steps or branch their code. For datetime2 the code

\expandafter\expandafter\expandafter\@dtm@parsepdfdatetime\pdfcreationdate\@dtm@endparsepdfdatetime

would work with legacy pdftex or LuaTeX 0.85 or later. In the case of pdftex or older LuaTeX, the second expansion step would try expanding D, so do nothing. In case of LuaTeX 0.85 or later (with luatex85 loaded) the double expansion would deliver the expected string.

More safely:

\ifdefined\pdffeedback
  \expandafter\@dtm@parsepdfdatetime
    \pdffeedback creationdate \@dtm@endparsepdfdatetime
\else
  \expandafter\@dtm@parsepdfdatetime
    \pdfcreationdate\@dtm@endparsepdfdatetime
\fi

However, another branching is needed in another part of datetime2 to make it independent of luatex85, where a check about the existence of \pdfcreationdate is performed.

Tricky one: Hans has this down as \def not \edef in the manual, so presumably we can't rely on expandability (as you note, in general that may not be the case for \pdffeedback). — Joseph Wright, Apr 30 '16 at 20:02
I understand the reason. But wouldn't it be more appropriate to use \edef in all cases where the emulated macros are “fixed”? It would prohibit some trouble with old code. — rolfn, May 02 '16 at 08:57

score 6 · Answer 2 · answered Jun 05 '16 at 20:30

This is fixed in datetime2 v1.5.1 (2016-06-05). I fixed it by defining a new command \dtm@pdfcreationdate:

\ifdef\pdfcreationdate
{%
  \edef\dtm@pdfcreationdate{\pdfcreationdate}%
}%
{%
  \ifdef\pdffeedback
  {%
     \edef\dtm@pdfcreationdate{\pdffeedback creationdate}%
  }%
  {}%
}

and then using \dtm@pdfcreationdate where I'd previously used \pdfcreationdate. This approach has the following advantages:

It doesn't modify \pdfcreationdate.
It allows for any potential future change to the definition of \pdfcreationdate that might required deeper expansion.¹
It works for new versions of LuaLaTeX where the user has chosen not to load luatex85 (or loads it after datetime2).

(XeLaTeX, which doesn't provide \pdfcreationdate, still triggers the fallback mode that computes the current time from \time, which lacks seconds and time zone.)

¹ I don't expect that to happen but, then again, I didn't expect LuaTeX to drop \pdfcreationdate.

luatex85: New definition of \pdfcreationdate is problematic

2 Answers2