# Why the luatex85 package and the luatex manual does not share the same definitions for \pdf…?

One can read in the luatex85 documentation:

LuaTEX 0.85 and 0.87 contain many changes from LuaTEX 0.80 as contained in TEXLive 2014. Most notably almost all the pdfTEX extended primitves with names \pdf... have been renamed or removed.

[...]

The LuaTEX manual lists suitable compatibility definitions that may be made so that documents can continue to use the old names. Mostly this package just consists of those definitions, with minor changes in some cases. (Mostly different choices over the use of \protected or \edef.)

Is there a reason other than "programming taste" for those different choices?

• I fear this question has no constructive answer. We can be grateful about great products like luatex, even if the authors willingly accept that end-users and package maintainers suffer from incompatible changes. So, we can make the following call to the luatex authors: "continue with the great work! And, if possible, please keep backwards compatibility even if your version number is below 1.0 -- we want to use your product". – Christian Feuersänger Aug 24 '16 at 18:44
• As to your question: I suggest that you send an email to the authors of luatex and discuss these things in private. I would prefer that great package authors do not to feel as if they have to justify themselfes here. I vote to close this question. – Christian Feuersänger Aug 24 '16 at 18:47
• @ChristianFeuersänger Probably my bad English here. I meant no offence to luatex team. They know what they do. I was just wondering why the authors of luatex85.sty (the package) chose to change a little the definitions given in luatex manual to keep backwards compatibility, that is regarding ’\protected’ and ’\edef’ (last sentence cited). See e.g. \def\pdffontname{\pdffeedback fontname} (luatex85.sty) versus \def\pdffontname{\numexpr\pdffeedback fontname\relax} (luatex manual). – cjorssen Aug 24 '16 at 21:43

The luatex85 definitions have the advantage that they are in code and tested in more cases (used in the wild in latex) so work in more cases.

Several of the definitions were tweaked in the first few releases. Usually it doesn't matter too much whether you use \def or \edef or whether or not you use \protected, and whether you terminate a number using a space or by \numexpr...\relax. But if you try the emulation in enough real world documents doing enough weird expansion contexts then you find that different commands need different types of emulation.

For example the case you mention in comments

\def\pdffontname{\pdffeedback fontname}              % (luatex85.sty)
\def\pdffontname{\numexpr\pdffeedback fontname\relax}% manual


In almost all cases this is going to be used as a number as in

\count@=\pdffontname


and either definition will work, but pdftex allows this to expand to a number in all contexts, and does not require \the so this plain tex document

\pdffontname\font

\bye


Is error free and typesets 1

The \numexpr version would produce

! You can't use \numexpr' in vertical mode.
\pdffontname ->\numexpr
\pdffeedback fontname\relax
l.5 \pdffontname
\font
?


unless you prefixed with \the

But the version without

\def\pdffontname{\pdffeedback fontname}

\pdffontname\font

\bye


does the right thing.

Sometimes as in

{\outputmode=1
\xdef\pdfcreationdate   {\pdffeedback creationdate}
}


we work harder to expand to the right thing in one expansion step as someone had a real package that did

....\expandafter\something\pdfcreationdate


and \something needed to access the expanded date not just the first level expansion of \pdffeedback creationdate, and also pdftex makes this available in both PDF and DVI modes whereas the LuaTeX feedback is only available if \outputmode` is 1.

It isn't clear that these considerations to make a robust emulation that works in the wild would necessarily clarify the manual which is giving the basic idea of how you might address the name changes that happened in LuaTeX 0.85, so we never thought it necessary to push these differences back to the LuaTeX team for the manual.