Menu

#2375 Unexpected (un)specifed linetypes

None
closed-not-a-bug
nobody
None
2021-06-13
2020-12-10
theozh
No

If you type show lt you will get the following message:

linetype 1,  linecolor rgb "dark-violet"  linewidth 1.000 dashtype solid pointtype 1 pointsize default
linetype 2,  linecolor rgb "#009e73"  linewidth 1.000 dashtype solid pointtype 2 pointsize default
linetype 3,  linecolor rgb "#56b4e9"  linewidth 1.000 dashtype solid pointtype 3 pointsize default
linetype 4,  linecolor rgb "#e69f00"  linewidth 1.000 dashtype solid pointtype 4 pointsize default
linetype 5,  linecolor rgb "#f0e442"  linewidth 1.000 dashtype solid pointtype 5 pointsize default
linetype 6,  linecolor rgb "#0072b2"  linewidth 1.000 dashtype solid pointtype 6 pointsize default
linetype 7,  linecolor rgb "#e51e10"  linewidth 1.000 dashtype solid pointtype 7 pointsize default
linetype 8,  linecolor rgb "black"  linewidth 1.000 dashtype solid pointtype 8 pointsize default
Linetypes repeat every 8 unless explicitly defined

To my understanding the following sentence is not correct.

Linetypes repeat every 8 unless explicitly defined

The linecolor repeats every 8 and the pointtype repeats every 15.
This means the linetype would repeat every 120, as the simple example shows (see attachment).

### linetypes repeat every 120
reset session

set samples 21
set key out maxrows 15
plot for [i=1:128] 0 w lp lt i ti sprintf("%d",i)
### end of code

Furthermore, there is another strange observation.
If I specify lt i, I would expect that I get the same linetype even if I haven't explicitely defined lt i..
However, this doesn't seem to be the case as the following example shows (see attachment).

### linetypes difffer from 9
reset session

set samples 21
set key out maxrows 15
plot for [i=1:12] i w lp lt i ti sprintf("%d",i), \
     for [i=1:12] i w lp lt i ti sprintf("%d",i)
### end of code

The linetypes start do differ from lt 9.
So, my guess is that the linecolor continues to repeat every 8 whereas the pointtypes continue somewhere depending on the "history", i.e. previous plots.
This is somehow unexpected and I would say undesired.

2 Attachments

Discussion

  • Ethan Merritt

    Ethan Merritt - 2020-12-10

    It is very much intended.

    gnuplot> help pointtype
         ...
        The first 8 point types are shared by all terminals. Individual terminals may
        provide a much larger number of distinct point types. Use the `test` command
        to show what is provided by the current terminal settings.
    

    The postscript terminal is the extreme case, I think, having 75 distinct point types.

    I have found the separate repeat counts for line colors and point types to be very useful when generating plots of experimental data from, e.g. tests done in 96 well plates. I can print off one "key" that shows the output of a command like your "LinetypesRepeatEvery120.png", and use it to identify outliers on a plot that superimposes all curves generated by conditions in a single plate. Suppose there's a curve that stands out from the rest; at a glance you can see that it is drawn with solid light blue squares, and therefore came from well #35. This works because the repeat number of colors and the repeat number of pointtypes are mutually prime. It's amazing how well it works to visually screen the results from thousands of conditions printed to just a few pages of plots.

    I've been carrying a patch that introduces a "set pointtype cycle N" command for my own use in preparing publication figures with this technique. This is (or was at the time) necessary because I needed to switch output to PostScript for publication and those 75 pointtypes for "set term post color" messed up my key of 96 distinct combinations. Unfortunately this patch doesn't help to increase the number of pointtypes used, only to decrease it. So I have not considered it suitable for general use.

     
  • theozh

    theozh - 2020-12-11

    Thank you Ethan, for your explanations.
    Maybe I haven't expressed myself clear enough.
    I don't want that linetype repeats every 8, and I don't want pointtype to repeat every 8 as well.
    If I needed, e.g. set pointtype cycle 8, I would have set the linetype in a do for loop.

    Actually, I agree, it's very good that linestyle repeats every 120, e.g. for the example you mentioned.
    Yes, I assumed that the variation of colors every 8 = 2*2*2 and the pointtypes variation every 15 = 3*5 was clearly intentionally.

    My point was the second example:
    If I don't explicitely define anything then I would expect that
    lt 9 would give the same line, in successive plots, i.e. color and pointtype are the same, independent of what was plotted before. But this is not the case in the second example.

    Well, it's no big deal then I have to explicitely define linetype.
    I was wondering why color variation just continues but pointtype variation had a "jump" depending on plotting history.

    Maybe I can make my point clearer with the following example:

    ### lt 9 is not equal lt 9
    reset session
    set samples 21
    set key out
    set multiplot layout 2,1
        plot x w lp lt 8, 2*x  w lp lt 8
        plot x w lp lt 9, 2*x  w lp lt 9
    unset multiplot
    ### end of code
    

    Why is linetype 9 different in the second plot? Color is the same but pointtype differs.

     

    Last edit: theozh 2020-12-11
    • Ethan Merritt

      Ethan Merritt - 2020-12-11

      Part of it may be a difference in expectations. Your example plots with lp, which selects a style that has both lines and points. It continues lt 9, which changes the lines part of that combined style. But it does not continue pt 9, which would equivalently change the points part of that style. My expectation would be the the following commands are logically parallel:
      with lines lt N
      with points pt N
      with linespoints lt N pt N

      Another part is the confusion left over from gradual introduction of color as a separate property. It took many versions of gnuplot to reach the current state. The attribute "linecolor" was introduced in version 4.2, but this was a separate property that
      had to be specified each time. Prior to version 4.6 each "linetype" still had an unchangeable color from a fixed sequence that varied by terminal type. The historical logic for this was that it was equivalent to selecting "pen #5" on a pen plotter, where the actual color was determined by the hardware. Gnuplot version 5 tries to treat relevant attributes - color, point symbol, linewidth, dash pattern, etc - equivalently. You can specify them on the fly or assign them in advance to the default sequence of "linetypes". This works pretty well, but it leaves open the question of what should happen if you request lt N where N has never been assigned an explicit set of properties.

      Relevant points that maybe could be made easier to find in the docs or help messages:

      1) Historically gnuplot used lt N to specify what color line was wanted (because color was the only thing distinguishing "linetypes"). In version 5 it would be more precise to use lc N or lc "colorname" if you specifically want to change the color.

      2) If linetype N has not been assigned a specific set of attributesi n a previouse set linetype command, then lt N will produce

             color = N % ncolors 
             pointtype = N % npointtypes 
             dashpattern = N % ndashpatterns
      

      ncolors is 8 by default but can be changed by set linetype cycle <ncolors>. That command was probably a mistake; it probably should have been set linecolor cycle <ncolors>. There is currently no mechanism for changing npointtypes or ndashpatterns, and they vary by terminal type.

      3) The statement you quote from show lt could probably be improved . The parallel description in the help text for set linetype is also not great

      The command "set linetype cycle 8" tells gnuplot to re-use these definitions for the color and linewidth of higher-numbered linetypes.

       

      Last edit: Ethan Merritt 2020-12-22
  • theozh

    theozh - 2020-12-11

    Thank you for the detailed explanations and the background. I see, it is a complex matter, heritage, compatibility, consistency, etc... I didn't want to complain, I was just wondering...

    I guess this "bug" report can be closed as "not-a-bug" or "works-for-me".

     
  • Ethan Merritt

    Ethan Merritt - 2020-12-22
    • status: open --> open-not-a-bug
    • Group: -->
    • Priority: -->
     
  • Ethan Merritt

    Ethan Merritt - 2021-06-13
    • status: open-not-a-bug --> closed-not-a-bug
     

Log in to post a comment.