[tex-live] LuaLaTeX potential problems

[David Carlisle]

On 14 May 2016 at 07:10, Petr Olsak <petr at olsak.net> wrote:
>
> Hello,
>
> I did try (only coincidentally) following document
>
> \documentclass[varwidth]{standalone}
> \begin{document}
> Nazdar.
> \end{document}
>
> processed by LuaLaTeX. It doesn't work with new LuaTeX where \pdfpagewidth
> primitive isn't accesible (in TeXlive pretest).
>
> There are thousands LaTeX packages and classes, they may be used in LuaLaTeX
> document. IMHO, there is very hight probability of problems simlilar like
> this. I don't understand why LuaLateX doesn't load luatex85.sty by default
> when it is generated.
>


Hi, yes as Karl pointed out on a message to this list at the start of
the tl2016 pretest
texlive "just" distributes what is provided to ctan, so this is the
wrong list for package
or luatex error reports.
It needs to be reported to Martin to update standalone (but I think he
knows:-) or
the latex project to suggest a change to the latex format.

> Of course, this is not my problem because I am not supporting LaTeX. OPmac
> macros were corrected, they work with new LuaTeX with etex.src format. And
> CSplain reads luatex85.sty when it is generated with LuaTeX.
>
> Petr Olsak
>
>

It is of course your choice to do that, and it's probably reasonable
in a plain based format
where the philosophy is presumably as with plain that the format
macros are a "starter kit"
without any claims to generality.

luatex85.sty is a "quick fix" that can hide some of the issues in the
new luatex so it's a good
thing to have available as the updates are not fully rolled out but it
isn't a good fix for a format
such as latex which unlike plain aims for robust solutions in the
format rather than aiming for
simple macros that work as examples and need to be extended for
particular cases.

We did consider adding luatex85 to the format, but while the renamed
primitives can be aliased
reasonably safely with \let the ones that are now macros using
\pdfextension etc have different
expansion behaviour. A safer approach to pdftex-luatex compatibility
would be like Heiko's pdftexcmds.sty
where you have wrapper macros on both engines so the expansion steps
are the same, but that doesn't help with the current
problem of compatibility with existing code using the primitives.

Perhaps more importantly it doesn't fix many packages where the
breakage is in lua code where the node library interfaces have changed
a lot.


There are thousands of packages but not thousands using \pdfxxx (we
searched the texlive tree to look:-) and even fewer authors of
packages needing updates.

So overall it's better to update code that claims to work with luatex
so that it does, in fact, work, even though that causes some short
term pain in terms of rolling out the necessary updates.

That said, the particular cases of \pdfpagewidth/height are (a) one of
the safest things to alias and (b) most commonly used.
We may yet add those two to the format, one of the things that we are
looking out for during the pretest is any reasonable cases where that
would help, ie cases that are not covered by package updates.

David