6

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?

3
  • 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". Aug 24, 2016 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. Aug 24, 2016 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, 2016 at 21:43

1 Answer 1

9

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.

7
  • I would object to luatex85's \protected definition of \pdflastobj. It prevents storing its current value in a macro for later use. The same for \pdflastannot, which I need, for example, append to a list that is finally inserted as value to the /Fields key in the /AcroForm PDF dictionary. The definitions are not \protect-ed in the luaTeX manual.
    – AlexG
    Mar 17, 2022 at 16:09
  • @AlexG we'd take any difference in behaviour from pdftex as a valid bug report if you have an example (you are better placed to make examples I suspect:-) The good thing is the package has co-authors so any that are wrong we can blame the co author. does pdftex's \pdflastannot expand in an edef?, I could check I suppose.... Mar 17, 2022 at 16:13
  • I let expand \the\pdflastannot in pdfbase.sty, line 342.
    – AlexG
    Mar 17, 2022 at 16:20
  • 1
    @AlexG yes exactly, with \the so that should work here as well. Mar 17, 2022 at 16:21
  • 1
    @AlexG yes as does \expandafter Mar 17, 2022 at 16:42

You must log in to answer this question.

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