#1284 Change contour colors with 'set linetype'.

Christoph Bersch


I'm having some issues when trying to change the color of the contour lines:

The basic script is:

set isosamples 50
set samples 50
set xrange[-2:2]
set yrange[-2:2]

set contour surface
splot '++' using 1:2:(exp(-($1)**2-($2)**2)) with lines

The contour lines start with linetype 3, so there is an offset of 2 with respect to the surface grid.

  1. When I change the first line type with

    set linetype 1 lc rgb 'black'

    the contour lines start with linetype 2, the offset is only 1. Is this intended?

  2. When I only want to change one of the contour lines to be black, but leave the other linetypes untouched, i.e. I have only the settings

    set linetype 3 lc rgb 'black'

    Theses settings are totally ignored, all line color are like in the default settings. What's going on here? I thought, set linetype should change the default linetypes, but then there shouldn't be a difference, whether I redefined them or not.


    set linetype 1 lc rgb 'black'
    set linetype 3 lc rgb 'red'

    works as expected.

  3. The linewidth settings are taken from the surface line settings. All other linewidth settings are ignored. I agree, that it makes sense to have all contour lines with the same linewidth, but they mustn't be forced to have the same linewidth as the surface lines.


    set linetype 1 lc rgb 'black'
    set linetype 2 lc rgb 'red' lw 3

    doesn't affect the contour's linewidth, while

    set linetype 1 lc rgb 'black' lw 2
    set linetype 2 lc rgb 'red'

    does, but also changes the surface properties.

I find some of these issues quite inconsistent, and this behaviour is not documented. Could you please comment on all questions, if the behaviour is intended, or if it's a bug? Afterwards I can submit a proposal for according additions to the documentation.



  • Ethan Merritt
    Ethan Merritt

    I am not seeing any of this behaviour. I attach a test script in which I attempt to reproduce the commands you show above, and the output from it. I get the same results using gnuplot 4.6.0, 4.6.3 and current cvs for 4.7.

    So either I misunderstand, or there is something different between our configurations. Let's try to figure out what is going on.

    I agree with you that line width is not handled equivalently to line color. This is largely due to historical artifact, since in most contexts "linetype" really meant "line color". I am of two minds about what the ideal behaviour would be for contours. 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. Or is it better to honor the individual line widths as well? That allows monochrome contours distinguished by width rather than color. The code currently does the first (modulo possible bugs).

    Passing through linewidth in hidden3d mode would be problematic, but that could maybe be documented as an exceptional case.

    Last edit: Ethan Merritt 2013-09-22
  • (colors)
    See the two attached pictures. When using 4.6.3, the new lt 3 is ignored (in #3) and is used only after also lt 1 was redefined (in #4). The offsets between surface and first contour are always 1.

    For 4.7 (2013-09-09), the default contour lines start with an offset of 2 (#2). Again, the lt 3 settings are ignored, the offset remains at 2 (#3). And in #4 the new line settings are used, and the offset is 1.

    I don't use any local setting files, maybe that's what makes the difference?

    Concerning the linewidth, I don't know the best way, but I think it is reasonable that one can change the linewidth of the contours independently from the surface lines.

  • Ethan Merritt
    Ethan Merritt

    Yes, I see. 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. The attached patch bypasses this by always claiming that the color was explicitly set, but it probably has side effects.

    A large part of the problem is that the program carries along two possibly conflicting types of information about each line. One is the original gnuplot "linetype" that historically controlled color, dash pattern, and width all in one number. This made sense for pen plotters. When we added more general properties for newer devices, e.g. 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. The idea was that devices that couldn't handle colors could still use the original linetype. 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. My patch sets the use_palette flag unconditionally, which bypasses the mismatch. But it may be handled badly by pen plotters and other legacy devices. 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.

    So anyhow, I may apply this patch to CVS after more testing, but not yet.
    I've added to my wishlist for version 5 that the use_palette flag should be removed altogether. Because it will touch a lot of code, the change will undoubtedly introduce or uncover more bugs similar to the current one. Thanks for your cooperation in testing and bug-finding.

  • Ethan Merritt
    Ethan Merritt

    The color issue is, I hope, fixed in CVS for 4.7. This required consolidating the treatment of set_color() commands by terminals that don't support RGB colors into a new generic routine null_set_color(). I am not comfortable applying this also to 4.6 right away, but the patch can be back-ported to 4.6 later if no further problems are found.

    I have not touched the line width handling.

  • Ethan Merritt
    Ethan Merritt

    • status: open --> pending-fixed
  • Ethan Merritt
    Ethan Merritt

    • status: pending-fixed --> closed-fixed