#2180 image plot not working with tikz backend

[Markus Ebner]

Hey guys,
I am having a small issue with the tikz backend (gnuplot Version 5.2 patchlevel 6 last modified 2019-01-01).
Trying to plot a simple heatmap using the image-plot hangs the complete latex process, producing megabytes of error-log nonstop. The example1.zip is a short example for this problem.

The error-log starts with this line:

"template_Article-gnuplottex-fig1.gnuplot" line 3: /usr/share/gnuplot/5.2/lua/gnuplot-tikz.lua:492: bad argument #2 to 'sf' (number has no integer representation)

I was able to fix it by changing the line from the error-message (492) from:

gw(sf("%02x%02x%02x", 255*t[cnt][1]+0.5, 255*t[cnt][2]+0.5, 255*t[cnt][3]+0.5))

to:

gw(sf("%02x%02x%02x", math.floor(255*t[cnt][1]+0.5), math.floor(255*t[cnt][2]+0.5), math.floor(255*t[cnt][3]+0.5)))

The above mentioned fix does, however, not seem to be enough when using lualatex (example2.zip with an editor like TeXstudio). It doesn't hang anymore, but the image is simply empty, only showing borders, tics and the scale to the right.

Thank you for this awesome software!

[Ethan Merritt]

On one of my machines both latex and lualatex process the input without error, although both require an intervening step to run the generated gnuplot commands manually:

Package gnuplottex Warning: Shell escape not enabled.
(gnuplottex)          You'll need to convert the graphs yourself..

I ran gnuplot_5.2.6 template_Article-gnuplottex-fig1.gnuplot
at that point and continued the latex/lualatex run.

latex -v
pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013/Mageia)
kpathsea version 6.1.1
lualatex -v
This is LuaTeX, Version beta-0.76.0-2017050100  (TeX Live 2013/Mageia) (rev 4627)
lua 5.2.3

However on another machine with a newer version of TeX Live I can reproduce the behaviour you report.

latex -v
pdfTeX3.14159265-2.6-1.40.19 (TeX Live 2018/Mageia)
kpathset version 6.3.0
lua 5.3.5

The two machines have identical files gnuplot-tikz.lua
I get the same results from gnuplot 5.2.6 and current 5.3.
So it appears that the key difference is either the TeX version or the lua version.
I'm not sure how to pursue this.

[Markus Ebner]

If your TeX installation on the older machine works without the math.floor() calls, while the newer does not, I would attribute that bug to the lua version (It's a lua error message in the log, after all).

Assuming your older TeX install produces a correctly looking figure, how about generating the template_Article-gnuplottex-fig1.tex file on the older TeX install, and trying to directly include it in the document with the newer TeX install?
If the old .tex file produces a defective image in the pdf, it should be a latex regression.
However, if the old .tex file produces a correct figure in the pdf, it's probably a regression in the way the .tex file is build.

Or is there more involved than that? (I'm not too deep into the topic)

[Ethan Merritt]

After applying your math.floor() fix, both machines generate identical template_Article-gnuplottex-fig1.tex files. That file works with lualatex on the older machine but gives a blank plot on the newer machine. So we have both a lua regression (now requires math.floor()) and a lualatex regression. On both machines pdflatex (which identifies as pdfTeX 3.14159265-2.6-1.40.19) works with no problem.

I will apply the math.floor() fix to gnuplot source but I don't know what to pursue with regard to lualatex.

Status:
work-around plot with image pixels works as-is
adding math.floor() fixes the lua step for use with pdflatex but not with lualatex

[Ethan Merritt]

I am struggling to debug this, but meanwhile here is a work-around:

\begin{figure}
        \begin{gnuplot}[terminal=tikz, terminaloptions={color size 7.3cm,6cm}]
                plot 'heatmap.data' using 1:2:3 notitle with image pixels
        \end{gnuplot}
\end{figure}

"with image pixels" bypasses the routine that is hitting an error and instead draws the image pixel-by-pixel. This can be very slow for large images, but otherwise should be fine for heatmaps.

[Markus Ebner]

I made a simpler example for reproduction (bypassing gnuplot), and opened a bug at tikz here.

Additionally, I just noticed: math.floor is probably not the most intelligent choice to mitigate the gnuplot-bug with. I only found math.modf that seems to do a proper rounding. This seems to work, but I did not have enough time to properly test how it behaves, but I guess you already had that in mind.

The image pixels workaround works for me. Thank you for your help with this!

[Henri Menke]

I have a fix and wanted to submit a merge request but unfortunately SourceForge is complete and utter garbage and decided to entirely screw my forked gnuplot repo. Please merge my fix using these commands:

git fetch https://git.code.sf.net/u/hmenke/gnuplot pgfsysdriver
git merge FETCH_HEAD

In case that doesn't work, I have attached the patch.

[Ethan Merritt]

Thank you.
I have merged it because your patch makes the code cleaner.

However lualatex template_Article still produces a blank plot with TeX Live 2018
(and pdflatex still works). Was this supposed to fix that or was it fixing something else?

[Henri Menke]

The patch was supposed to fix it and it definitely does for the latest release of PGF.
Beyond that, I can't reproduce. I am using the example that OP has posted to the PGF bugtracker (https://github.com/pgf-tikz/pgf/files/3269675/example.zip) and it works with TeX Live 2016, 2017, 2018, and 2019.

[Ethan Merritt]

Yup. It works for me now. I previiously failed to regenerate/reinstall the style file from the patched source before testing. Thanks again.

[Henri Menke]

I have some more little improvements to gnuplot-lua-tikz-common.tex. You can merge them in the same way as mentioned above if the SourceForge Git server decides to accept my push at some point in the future. Right now it just hangs. So glad I moved PGF/TikZ to GitHub...
Just in case, the patch is attached as well.

[Ethan Merritt]

Applied to 5.3