#1491 tikz term and dashtype strangeness?

[Ethan Merritt]

posted by gnutron on the Discussion forum

I am having a strange problem with dashtypes. If I use the tikz term (and then process the output with pdflatex to make a nice pdf) I see that the dashtype command makes not only the line dashed, but also the error bar on the data point (which I don't want dashed). If I use the pngcairo terminal the problem goes away. Am I doing something stupid?
Code (using gnuplot 5.0rc2:

set term tikz standalone size 5in,7in 
set output "new.tex"

set multiplot layout 2,1 
set lmargin at screen 0.15
set rmargin at screen 0.85
set bmargin at screen 0.51
set tmargin at screen 0.85
unset label
set xrange [-10:10]
set xtics format ''
set style line 1 lc rgb 'red' 
set style line 2 lc rgb 'blue' pt 7 ps 2
set style line 3 dt 2 lc rgb 'dark-violet'
plot \
  x ls 1,\
  x**2 ls 2
set lmargin at screen 0.15
set rmargin at screen 0.85
set bmargin at screen 0.15
set tmargin at screen 0.49
set format x
set yrange [-1:1]
plot \
  x**3 ls 3,\
  '-' u 1:2:3 w yerr ls 2
0 0 0.3
e
unset multiplot

[Christoph Bersch]

The dashtype isn't reset to solid, when internally a type of -1 is given to the dashtype terminal function. The attached patch should fix this.

[gnutron]

I don't suppose I could get a patch for the 5.0rc2 version?
Thanks either way!

[Ethan Merritt]

I get the following error after applying this patch, build, install, run the test script in the bug report:

! Package pgfkeys Error: I do not know the key '/tikz/gp dt 0' and I am going t
o ignore it. Perhaps you misspelled it.

And the output still shows the bug.

I don't really understand the lua script, but could it be that the patch should have:

 pgf.styles.dashtypes = {

+  [0] = {"gp dt 1", "solid"}, 
   [1] = {"gp dt 1", "solid"},

rather than "gp dt 0"?

[Christoph Bersch]

The problem is, that make doesn't rebuild the respective tex files when only the lua script was changed.

So you must do a

rm share/LaTeX/gnuplot-lua-tikz* && make && make install

to rebuild and reinstall the tex files.

[Ethan Merritt]

Working now. Thanks.

[gnutron]

So I applied your patch to my 5.0rc2 manually, and it is better now. Something is still not quite right though. See example attached. The dashtype 1 (solid line) is not recovered after others are used.

[Christoph Bersch]

Yes, I do also see this.

At the moment I cannot track down where this comes from. I tried to debug this, but it seems that for ls 9 the term.dashtype isn't called (but for other terminals it works fine). Using any other dt for ls 9 or not using a dt works fine.

[Ethan Merritt]

From: John Breckenridge
Date: Today 06:16:54 AM

Re: gnuplot-5.1

A side effect of the October 3, 2014 changes in term/lua/gnuplot-tikz.lua
is that 'set tics scale 0' changes grid lines from dotted to solid.
As this happens only with tikz, it probably isn't intended.

System: Slackware64-14.1 with PGF/TiKZ-2.10 in TeXLive-2013.

### EXAMPLE:
set term tikz standalone
set output 'quirk1.tex'
set grid
set tics scale 0      ## grid lines become solid (surprise)
#set tics scale 0.01  ## grid lines are dotted (as expected)
plot x
### END EXAMPLE

Thanks,

John Breckenridge

[Christoph Bersch]

I'll have a look at this in the next days and try to fix it.

[Christoph Bersch]

Ok, I got a bit confused regarding when to apply a dashtype and when not. I had missed that LT_AXIS and LT_SOLID should also affect the dashtype, and that no separate call to term.dashtype is done in those cases.

The attached patch hopefully fixes this. As test document I used:

reset
set term tikz size 7in,7in fontscale 1.5 standalone linewidth 3 dashlength 0.5
set output "fplot.tex"

set grid
set tics scale 0
set ytics -11,2
set xrange [-10:10]
set yrange [-12:10]
set style line 1 dt 1 lc 1 lw 2 
set style line 2 dt 2 lc 2 lw 2 
set style line 3 dt 3 lc 3 lw 2 
set style line 4 dt 4 lc 4 lw 2
set style line 5 dt 5 lc 5 lw 2
set style line 6 dt 6 lc 6 lw 2 
set style line 7 dt 7 lc 7 lw 2
set style line 8 dt 8 lc bgnd lw 2
set style line 9 dt 1 lc 9 lw 2
set style line 10 dt 5 lc 3 lw 2

set key outside

set object rectangle from screen 0,0 to screen 1,1 fillcolor rgb '#66000' fillstyle solid noborder behind

plot 8 t 'dt 1' ls 1, 6 t 'dt 2' ls 2, 4 t 'dt 3' ls 3, 2 t 'nodraw' lt nodraw, 0 t 'dt 5' ls 5, -2 t 'dt 6' ls 6, -4 t 'dt 7' ls 7, -6 t 'dt 8' ls 8, -8 t 'dt 9' ls 9, -10 t 'dt 5' ls 10

Attached you also find the result of the test document.

[Ethan Merritt]

I've applied this to CVS for 5.0 and 5.1
Let me know if there are any more fixes or tweaks needed.

[gnutron]

This may be more of a "feature" than a "bug" but I noticed that the pt 12 and pt 13 (open and solid diamonds) don't look like squares that have been rotated by 45 degrees in the tikz terminal. They look more like skinny diamonds. This doesn't match the pngcairo term for example. It would look cooler if they were squares that were rotated by 45 degrees (IMO).

[Christoph Bersch]

I would've guessed, that the tikz-way of drawing these diamonds is the better one. If you rather want rotated squares, you can redefine the respective point marks using the header terminal option:

newmarks = ' ''\tikzset{gp mark 12/.style={mark=square,every mark/.append style={rotate=45}}}'.\
           '\tikzset{gp mark 13/.style={mark=square*,every mark/.append style={rotate=45}}}'' '
set terminal tikz header @newmarks standalone
set output 'pointtypes.tex'
set yrange [0:14]
set samples 11
unset key
plot for [i=1:13] i pt i ps 2 with points

Note, that you'll need the fix I posted in https://sourceforge.net/p/gnuplot/bugs/1503/ to use the header option.

[gnutron]

Ah, neat. Thanks for the tip!