Thanks for your cooperation in testing and bug-finding. Because it will touch a lot of code, the change will undoubtedly introduce or uncover more bugs similar to the current one. I've added to my wishlist for version 5 that the use_palette flag should be removed altogether.
#Gnuplot linetype Patch#
So anyhow, I may apply this patch to CVS after more testing, but not yet. For instance I tested with "set term pbm color" and found that setting the already red linetype 1 explicitly to red made it turn unexpectedly black. But it may be handled badly by pen plotters and other legacy devices. My patch sets the use_palette flag unconditionally, which bypasses the mismatch. The current case is an example of what can happen if the color of the stored linetype doesn't match the color in the color field. With the exception of ':', Octave's linestyles can be easily rendered using gnuplot by specifying the dashtype to be the linestyle. The idea was that devices that couldn't handle colors could still use the original linetype. I also stumbled across syntax options for gnuplot's 'dashtype' that I was not aware of. color determined by a pm3d palette coordinate or 24-bit RGB value, this went into a separate field that is only used if the flag lp->use_palette is set. When we added more general properties for newer devices, e.g.
One is the original gnuplot "linetype" that historically controlled color, dash pattern, and width all in one number. The attached patch bypasses this by always claiming that the color was explicitly set, but it probably has side effects.Ī large part of the problem is that the program carries along two possibly conflicting types of information about each line. In particular if the first linetype used for contouring has not been given an explicit color spec, then color specs for all contours are ignored and the indexing is one off. Passing through linewidth in hidden3d mode would be problematic, but that could maybe be documented as an exceptional case. It doesnt seem to have any of the set pm3d border/linetype/linecolor/etc options.
#Gnuplot linetype code#
The code currently does the first (modulo possible bugs). Or is it better to honor the individual line widths as well? That allows monochrome contours distinguished by width rather than color. Is it better to give them all the same width but cycle through colors? That allows you to explicitly give two sets of contours on the same plot where they are distinguished by width. I am of two minds about what the ideal behaviour would be for contours. This is largely due to historical artifact, since in most contexts "linetype" really meant "line color". I agree with you that line width is not handled equivalently to line color. Let's try to figure out what is going on.
So either I misunderstand, or there is something different between our configurations. I get the same results using gnuplot 4.6.0, 4.6.3 and current cvs for 4.7. I attach a test script in which I attempt to reproduce the commands you show above, and the output from it. Is this a gnuplot 5 problem or an ubuntu package problem? I have installed gnuplot5-qt and gnuplot5-X11 just to cover my bases.I am not seeing any of this behaviour. They are freely available and now also included in the gnuplot-palettes repository on github. Especially viridis you might have seen already as this will be the new default in Matplotlib 2.0. Set style line 4 lw 6 lc rgb 'forest-green' linestyle Gnuplotting Matplotlib colormaps September 3rd, 2016 2 Comments Matplotlib has four new colormaps called viridis, plasma, magma, and inferno.
Code follows, set terminal postscript eps enhanced color 'Times, 25' The script still works if I use gnuplot 4 instead of gnuplot 5. The title says it all mostly, I can no longer make dashed lines in the Postscript terminal in gnuplot.