#2084 Broken size of tikz output in gnuplot 5.3

[Eldrad Ulthran]

Hello,

when specifying the output size of the tikz terminal in cm I get some weird behaviour. set term tikz color size 16.0cm,11.2cm produces correct output, but when I change the width to 16.1cm, the size calculation explodes, e.g. the last line from the resulting tex file is:

%% coordinates of the plot area
\gpdefrectangularnode{gp plot 1}{\pgfpoint{1.380cm}{0.985cm}}{\pgfpoint{-2147483.648cm}{10.891cm}}

tikz then complains that the dimensions are too large (obviously).

I use Version 5.3 patchlevel 0 last modified 2018-11-02, compiled on OpenSuse Leap 15.0 with the option --with-texdir=/usr/share/texmf/tex/latex/gnuplot

[Ethan Merritt]

The strange number in the output file (-2147483) is an internal flag meaning "invalid coordinate value". It should never make it all the way to a terminal driver. This would seem to indicate that there is some place in the code that fails to check for this flag. Can you provide a comple reproducing script with data so that we can track down where in the code this check is missing?

[Eldrad Ulthran]

Even the simplest code produces this error for me:

set term tikz color size 16.1cm,11.2cm
set out "gnutikztest.tex"
plot sin(x)
unset out
unset term

Please find attached the resulting .tex file.
I should add that upon the plot command gnuplot reports:

warning: Too many axis ticks requested (>1e+01)
warning: Terminal canvas area too small to hold plot.
Check plot boundary and font sizes.
warning: Too many axis ticks requested (>1e+01)
warning: Too many axis ticks requested (>4)

This seems to be related exclusively to tikz output; cairolatex is working as intended.

[Ethan Merritt]

I have now been able to reproduce this on a test machine running Mageia Cauldron, which has lua 5.3.4 installed. My other machines have lua 5.2, and indeed I can confirm that the test case fails when gnuplot is built with lua 5.3 but works when it is built with lua 5.2.

I will investigate further, but I am not very familiar with lua so I could use some help.

[Ethan Merritt]

Here is what I found. Gnuplot retrieves parameter values from lua using the construct

value = (lua_isnumber(L, -1) ? (int)lua_tointeger(L, -1) : DEFAULT_VALUE

This was was working fine in lua 5.2, but is not working correctly in lua 5.3. The difference apparently comes down to what values are acceptable input to lua_tointeger. Contrary to its name, the function does not convert an arbitrary number to an integer. Rather it takes things that already have integral value and marks them as "integer" rather than "float". 5.3 appears to be more strict about whether a floating point value is "integral", and bad luck for you is seems that the floating point result of 16.1 x SCALE_FACTOR is not recognized as an integral value. I suppose that floating point precision jitter is large enough that the result comes out 16100.000001 rather than 16100.0 or some such trivial imprecision. Anyhow, as a result lua_tointeger fails to return the requested value and bad things happen.

I find this weird and I can't rule out an actual bug in the lua 5.3 code base.

Regardless, replacing (int)lua_tointeger(L, -1) with (int)lua_tonumber(L, -1) works in my testing with both lua 5.2 and lua 5.3 so that is my proposed fix. I will make that change everywhere in the gnuplot lua terminal driver.

If anyone understands lua better than I do and can spot a flaw in my diagnosis, please chime in! Why on earth would the language provide a function named "tointeger" that does not actually convert any in-range number to an integer?

[Eldrad Ulthran]

Thank you for your quick help, now it's working for me!

[Agustin Martin Domingo]

For the records I found a similar problem in the tikz terminal when I use more than one non null decimal in y scale as in

set term tikz monochrome originreset scale 1.05,0.65
set term tikz monochrome originreset scale 1.05,0.61

This does not happen if only one decimal is used or if the second one is 0.

set term tikz monochrome originreset scale 1.05,0.60
set term tikz monochrome originreset scale 1.05,0.6

I guess this problem has the same origin.