# Is lualatex supposed to be a superset of pdflatex? (regarding production of PDF)

In other words, is it a bug if lualatex cannot compile a document that pdflatex can?

Based on the answers to this question

How to expand TeX's "main memory size"? (pgfplots memory overload)

I decided to give a try to lualatex to resolve the issue of dynamic memory allocation, specificially for pgfplots. Although there are still memory issues in extreme cases, I found that lualatex is more resilient to failure, and had been using it by default... until I tried it for 3D pgfplots. I found that is fails to produce a good PDF for this MWE:

\documentclass{article}
\usepackage{pgfplots}
\begin{document}
\begin{tikzpicture}
\begin{axis}
\addplot3[surf, shader = interp] %shader interp offends lualatex
coordinates {
(-3, -3, 4.07584)(-1, -3, 2.96859)(1, -3, 3.00208)(3, -3, 4.1488)\par
(-3, -1, 3.00208)(-1, -1, 1.10114)(1, -1, 1.18849)(3, -1, 3.1004)\par
(-3, 1, 3.06798)(-1, 1, 1.26984)(1, 1, 1.34629)(3, 1, 3.16425)\par
(-3, 3, 4.22049)(-1, 3, 3.16425)(1, 3, 3.1957)(3, 3, 4.29098)\par
};
\end{axis}
\end{tikzpicture}
\end{document}


pdflatex works perfectly, but lualatex produces a PDF that is corrupted, evince shows the wrong polygons and Acrobat Reader gives a "drawing error occurred". The offending feature seems to be the "shader = interp" option in the 3D plot.

versions: TeXLive 2012, acroread 9.4.7, evince 3.4.0.

An acceptable answer can be a confirmation that this is a bug in lualatex.

• mine is beta-0.70.2-2012052721 (TeX Live 2012/Debian). xpdf version 3.02 also fails (segfaults) when reading the resulting lualatex PDF. – alfC Jun 2 '12 at 0:30
• Yes, LuaTeX is mostly a superset of pdfTeX. But that doesn't rule out errors in the TeX macros using it (as seems to be happening here). – Reinstate Monica - M. Schröder Jun 2 '12 at 11:53
• @MartinSchröder FYI: there is a difference how lualatex outputs binary tokens which have catcode 12: pdflatex generates the corresponding binary byte whereas lualatex applies some unicode scheme and destroys (=invalidates) the output streams. pgfplots now uses LUA code to generate binary output. – Christian Feuersänger Jun 2 '12 at 13:22

## 2 Answers

I can confirm that there are differences between LuaLatex and pdflatex: the pgfplots driver which produces shader=interp does not work for LuaLateX until and including pgfplots 1.5.1 (the problem is related to the production of binary output in the pgfplots drivers).

This has been fixed in the development version of pgfplots; it will become part of the next release of pgfplots.

The unstable version of pgfplots is available for download on http://pgfplots.sourceforge.net/ (on your own risk).

• lualatex+pgfplots+shader=interp is giving problems again: ! LuaTeX error ...texlive/texmf-dist/tex/generic/pgfplots/lua/pgfplots.lua:24: a ttempt to call global 'unpack' (a nil value) stack traceback: ...texlive/texmf-dist/tex/generic/pgfplots/lua/pgfplots.lua:24: in function 'pg fplotsGetLuaBinaryStringFromCharIndices' [string "\directlua "]:1: in main chunk. \pgfplotsbinarytoluabinary ...CharIndices({#1}); }. I am using version TeXLive 2013 pgfplots 29531.1.1.7-0.1fc19 (I think it is version 1.8) – alfC Nov 11 '13 at 2:14
• @alfC could you send me a complete bug report (i.e. the resulting .log file of lualatex, your lualatex version, and the input .tex file) by mail? You can find my address on top of the pgfplots manual. – Christian Feuersänger Nov 15 '13 at 6:41
• @alfC thinking about it, it sounds more like tex.stackexchange.com/questions/142156/… . An upgrade to pgfplots 1.9 will help. – Christian Feuersänger Nov 15 '13 at 21:30

I understand that you are experiencing problems with alternative solutions (shader=flat combined with opacity in Is there any way to remove mesh lines completely in a pgfplots faceted 3d plot? ). Taking into account that pgfplots can encode the shader information in some HEX encoding as well, I want to add the following

PATCH SUGGESTION.

For the records: use this only if you are running pgfplots 1.5.1 . Future versions will have a better fix (see my other answer).

Do the following if you want to use the patch:

1. deactivate pdf compression (see below).

2. introduce the following lines into your header, after loading pgfplots

:

\usepackage{pgfplots}
\makeatletter
\def\temp{ (git show 1.5.1-127-g1088bd7 )}%
\ifx\pgfplotsrevision\temp
\message{PATCHING INTERP SHADER FOR LUATEX}
\def\pgfplotslibrarysurf@filter@encode{ASCIIHexEncode}%
\def\pgfplotslibrarysurf@filter@decode{ASCIIHexDecode}%
\fi
\makeatother


your example is

\pdfcompresslevel=0

\documentclass{article}

\usepackage{pgfplots}

\makeatletter
\def\temp{ (git show 1.5.1-127-g1088bd7 )}%
\ifx\pgfplotsrevision\temp
\message{PATCHING INTERP SHADER FOR LUATEX}
\def\pgfplotslibrarysurf@filter@encode{ASCIIHexEncode}%
\def\pgfplotslibrarysurf@filter@decode{ASCIIHexDecode}%
\fi
\makeatother

\begin{document}
\begin{tikzpicture}
\begin{axis}
\addplot3[surf, opacity=0.8, shader=interp] %shader interp offends lualatex
coordinates {
(-3, -3, 3.57005)(-2.8125, -3, 3.50682)(-2.625, -3, 3.4438)\par
(-3, -2.8125, 3.5075)(-2.8125, -2.8125, 3.44005)(-2.625, -2.8125, 3.37252)\par
(-3, -2.625, 3.4453)(-2.8125, -2.625, 3.37336)(-2.625, -2.625, 3.301)\par
(-3, -2.4375, 3.38377)(-2.8125, -2.4375, 3.3071)(-2.625, -2.4375, 3.22959)\par
};
\end{axis}
\end{tikzpicture}
\end{document}


Background information: this encodes the data stream in Ascii Hex encoding instead of binary encoding. This will enlarge the stream. The \pdfcompresslevel=0 is necessary due to a bug in luatex and pdftex: they do not accept custom data stream filters if compression is active as well (I already reported the bug).

REPEAT: this patch is UNNECESSARY for more recent versions.

• thanks for the detailed answer. Yes, the reason I was using 'faceted/flat' was to workaround the 'interp' bug. Since I don't have 1.5.1 I tried it with a previous version (after removing the conditional) and it also works as a workaround. This may merit a separate question, but is it possible to feed pgfplots with hexadecimal encoded data?, it looks to me as if a lot of compilation time is wasted reading numbers of the coordinates (?). – alfC Jun 2 '12 at 22:56
• I'm glad the patch helps. Concerning your performance question: the short answer is "no". The long answer is: yes, if you also provided the decoder: pgfplots would decode it, compute limits, transform to internal coords which fit into the viewer's coordinate system, encode those internal coords, write that to a stream. There would be no timesaving. Optimization is a valid feature request, though, and is current work in progress. – Christian Feuersänger Jun 3 '12 at 13:45