#2408 "set xtics add ()" creates unwanted artefact dashed vertical line

[Werner Simbuerger]

Gnuplot version: 5.2 patchlevel 6
OS: Debian 10 (Buster)

Bug description:

The command:

set xtics add ("10^{-12}" 1e-12, "10^{-11}" 1e-11, "10^{-10}" 1e-10, "10^{-9}" 1e-9, "10^{-8}" 1e-8, "10^{-7}" 1e-7, "10^{-6}" 1e-6, "10^{-5}" 1e-5, "10^{-4}" 1e-4, "10^{-3}" 1e-3, "10^{-2}" 1e-2, "10^{-1}" 1e-1, "10^{-0}" 1e-0, "10^{1}" 1e1, "10^{2}" 1e2, "10^{3}" 1e3, "10^{4}" 1e4, "10^{5}" 1e5, "10^{6}" 1e6, "10^{7}" 1e7, "10^{8}" 1e8, "10^{9}" 1e9, "10^{10}" 1e10, "10^{11}" 1e11, "10^{12}" 1e12, "10^{13}" 1e13)

creates an unwanted artefact dashed vertical line nearby the y-label in case of:

set xrange[1e5:1e10]

Demo: <<plot1.plt>> see <<plot1.pdf>></plot1.pdf></plot1.plt>

The bug does not appear in case of:

set xtics add ("10^{5}" 1e5, "10^{6}" 1e6, "10^{7}" 1e7, "10^{8}" 1e8, "10^{9}" 1e9, "10^{10}" 1e10)

which means that the range of "set xtics" must match the "set xrange".

Demo: <<plot2.plt>> see <<plot2.pdf>></plot2.pdf></plot2.plt>

General observation:

The presented bug (<<plot1.plt>> see <<plot1.pdf>>) does nit exist in very early gnuplot revision. But it does exist in all recent revisions on Windows as well as Linux platform.</plot1.pdf></plot1.plt>

Unfortunately I can not mention the earlier Gnuplot revision number where this bug does not exist. Because now for probably more than 10 years I did the workaround to match the "set xtics" range with the "set xrange" range.

It would be comfortable again, if the "set xtics add ()" command can cover the full log scale and "set xrange" just picks the correct values out of the full range of "set xtics add ()".

Best regards,
Werner

[Hans-Bernhard Broeker]

The workaround would not even be needed at all if you just let gnuplot do the work for you.

set format x '10^{%T}'

[Werner Simbuerger]

This is indeed a very elegant solution.

Using:

set format x '10^{%T}'

the unwanted "artefact dashed vertical line" near the y-label does not show up anymore.
Demo: plot1a.plt and plot1a.pdf

This is of course the better way to define the exponential x-format.

But, maybe the origin of the "dashed line artefact" due to "set xtics add ("10^{-12}" 1e-12, ... )" can be corrected in the source code in order just to be backward compatible with old plot files which use "set xtics add (...)".

[Gabriel Dupras]

Here is a minimal working example:

set lmargin 40
set xrange[1e5:1e10]
set yrange [-50:0]
set logscale x
set xtics add (1e2, 1e4)
set grid
plot -40

We see that there is a vertical dashed line where x = 1e2 and x = 1e4 would be located if the x-axis were extended. Every terminal I've tried does the same: qt, wxt, png, pngcairo, pdfcairo.

Is this a bug or a feature?

[Werner Simbuerger]

I was able to verify the same behavior in <<plot3.plt>> and <<plot3.pdf>></plot3.pdf></plot3.plt>

At least in earlier Gnuplot release there were probably no objects created outside plotting area without any plot area margin extension.

If it is intended to keep the "feature" of grid line extensions outside plotting area without any label, it is probably enough to extend the user manual, e.g.:

http://www.gnuplot.info/docs_5.4/Gnuplot_5_4.pdf

Page 149, paragraph "Format":
include example
set format x '10^{%T}'
with reference to format specifier tabular on page 150.

Page 218, paragraph "Xtics list":
include example

set xtics add ("10^{5}" 1e5, "10^{6}" 1e6, "10^{7}" 1e7, "10^{8}" 1e8, "10^{9}" 1e9, "10^{10}" 1e10)
set format x '10^{%T}'

[Ethan Merritt]

Two thoughts:
1) I am not convinced that it is a bug for the program to draw a tic mark at a location the user specifically asked for.
2) The current code allows for a little bit of uncertainty at the very ends of an axis range. The idea is that if you ask for a tic that is only slightly outside the axis range, it is intentional and should be drawn. The uncertainty is set as follows (SIGNIF is defined in some header as 0.01).

        double uncertain = (axis->max - axis->min) / 10;
        double internal_min = axis->min - SIGNIF * uncertain;
        double internal_max = axis->max + SIGNIF * uncertain;

This calculation is clearly wrong for log scale axes, and probably a bad idea for any non-linear axis.

I will change this to set the uncertainty to zero for any nonlinear axis scaling.

[Werner Simbuerger]

I agree with 1), because
set format x '10^{%T}'
is the preferred and elegant solution to solve the original problem.