Hello everybody, I am using Gnuplot on OS X 10.11.2, and I would like to plot a three-dimensional parametric plot with dashed lines with the epslatex terminal. I have run into this discussion, which states that there is a bug as for plotting dashed lines with epslatex, and that the problem has been fixed in the CVS version. I installed the gnuplot CVS version, so now when I start gnuplot I get
G N U P L O T
Version 5.1 patchlevel 0 last modified 2017-05-08
With this version, I run the following commands
set term epslatex dashed
set output "figtest.tex"
set parametric
set urange [0:2*pi]
splot cos(u), sin(u), u dashtype 2 lw 2
The result is in this file http://ge.tt/5tgtt2k2 . As you can see, the lower part of the parmetric curve is dashed, but the dashes are not correctly displayed for the rest of the curve. Do you know how to fix this without changing terminal?
Thank you.
Last edit: James 2017-05-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some experimentation with older gnuplot versions seems to show that the postscript terminal always had problems with dashed lines in parametric plots. So the error is reproducible but has nothing to do with version 5 or with OSX or with LaTeX.
The postscript component of the output produced by the pslatex and epslatex terminals is generated by the postscript terminal, so these suffer from the same limitation.
You have several alternatives, any of which should be sufficient by itself
1) Use a different terminal, e.g. cairolatex
2) Do not use parametric mode. Your plot can be described instead as shown below.
unset parametric
splot sample [t=0:2*pi] '+' using (cos($1)):(sin($1)):($1) \
with lines dashtype 2 lw 2
3) Your command implies a surface, not a line. The badness of the line comes from superimposing several dashed lines on top of each other to make this 0-width surface. You can reduce the number of superimposed lines and hence reduce the degradation of the dash pattern by saying
set isosamples 2,2
Last edit: Ethan Merritt 2017-05-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After a deeper dive into gnuplot history.
This glitch in postscript output of dashed lines in certain plots was introduced in version 4.2 as a work-around for a bug in ghostscript/ghostview. The relevant code contains a comment
/ Ghostscript has a "pile-up of rounding errors" bug: a sequence of many rmove's or rlineto's does not yield the same line as move's or lineto's. Therefore, we periodically force an update of the absolute position. There was a case when 400 rlineto's were too much, so let's go a little bit higher than the default function sampling rate in gnuplot. This runs into a second ghostscript bug, that mixing relative and absolute lineto with no intervening 'stroke' is ridiculously slow to render. So we stroke the partial line, update the position in absolute terms, then continue. This whole section can go away if ghostscript/gv is fixed. /
That was 10 years ago. I don't know if the ghostscript bugs were fixed or not but maybe we should remove the gnuplot workaround and see if anyone reports a problem viewing the output with current generation tools.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everybody, I am using Gnuplot on OS X 10.11.2, and I would like to plot a three-dimensional parametric plot with dashed lines with the epslatex terminal. I have run into this discussion, which states that there is a bug as for plotting dashed lines with epslatex, and that the problem has been fixed in the CVS version. I installed the gnuplot CVS version, so now when I start gnuplot I get
With this version, I run the following commands
then I create the file figtestc.tex available here http://ge.tt/1ZQjt2k2 , and run
The result is in this file http://ge.tt/5tgtt2k2 . As you can see, the lower part of the parmetric curve is dashed, but the dashes are not correctly displayed for the rest of the curve. Do you know how to fix this without changing terminal?
Thank you.
Last edit: James 2017-05-10
Some experimentation with older gnuplot versions seems to show that the postscript terminal always had problems with dashed lines in parametric plots. So the error is reproducible but has nothing to do with version 5 or with OSX or with LaTeX.
The postscript component of the output produced by the pslatex and epslatex terminals is generated by the postscript terminal, so these suffer from the same limitation.
You have several alternatives, any of which should be sufficient by itself
1) Use a different terminal, e.g. cairolatex
2) Do not use parametric mode. Your plot can be described instead as shown below.
3) Your command implies a surface, not a line. The badness of the line comes from superimposing several dashed lines on top of each other to make this 0-width surface. You can reduce the number of superimposed lines and hence reduce the degradation of the dash pattern by saying
Last edit: Ethan Merritt 2017-05-11
After a deeper dive into gnuplot history.
This glitch in postscript output of dashed lines in certain plots was introduced in version 4.2 as a work-around for a bug in ghostscript/ghostview. The relevant code contains a comment
/ Ghostscript has a "pile-up of rounding errors" bug: a sequence of many
rmove's or rlineto's does not yield the same line as move's or lineto's.
Therefore, we periodically force an update of the absolute position.
There was a case when 400 rlineto's were too much, so let's go a little
bit higher than the default function sampling rate in gnuplot.
This runs into a second ghostscript bug, that mixing relative and absolute
lineto with no intervening 'stroke' is ridiculously slow to render.
So we stroke the partial line, update the position in absolute terms,
then continue. This whole section can go away if ghostscript/gv is fixed.
/
That was 10 years ago. I don't know if the ghostscript bugs were fixed or not but maybe we should remove the gnuplot workaround and see if anyone reports a problem viewing the output with current generation tools.
The second option works very well, thank you.