plot 'data.txt' u 1:2 w lp, '' u 1:3 w lp, '' u 1:4 w lp
the three linespoints will come out certain colors and style. Can I
redefine them wihout changing this plot command? I guess I want to change
the style without altering the core of the pre-existing gnuplot scripts.
Thanks for your help.
s
[...]
> the three linespoints will come out certain colors and style. Can I
> redefine them wihout changing this plot command?
Only on a limited selection of terminals (mostly the GUI window
drivers, plus the GD family). For all others, you'ld have to
postprocess gnuplot's output instead.
Well, unless you're brave enough to just modify the colour tables of
the drivers you're interested in, right in the source code, and
rebuild your own private gnuplot.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
How would I do it on those terminals?
> For all others, you'ld have to
> postprocess gnuplot's output instead.
Can I do postprocessing on Png terminal?
> Well, unless you're brave enough to just modify the colour tables of
> the drivers you're interested in, right in the source code, and
> rebuild your own private gnuplot.
Maybe I should give this a try. I want a fix for that arrow problem as
well, so I might kill two birds with one stone.
Thanks.
s
It seems an obvious question, but is there some reason
you cannot use the line style commands that gnuplot provides?
This gives you a lot of control over the line and point style
properties, and allows you to change the definitions without
editing the plot commands themselves.
For example:
-----------------
set style line 1 linetype 3 pointtype 5 linewidth 3
set style line 2 linetype -1 pointtype 5 linewidth 3
# First plot get blue and black lines, both thick and with pt 5
set style func linespoints
plot sin(x) ls 1, cos(x) ls 2
set style line 1 linetype 2 pointtype 3 linewidth 1
set style line 2 linetype 2 pointtype 6 linewidth 1
# Second plot uses exactly the same command sequence, but gets
# two thin green lines distinguished by having different point
# types
set style func linespoints
plot sin(x) ls 1, cos(x) ls 2
--
Ethan A Merritt
> It seems an obvious question, but is there some reason
> you cannot use the line style commands that gnuplot provides?
What I was trying to do was to not have the thingie "ls 1" in the plot
command itself. I have pre-existing scripts and wanted to change plot
defaults whout editing my scripts scripts. Otherwise now I have to add "ls
1", "ls 2", "ls 4" etc. to the plot commands itself. But given the hassle
of checking and compiling, it might be just better to do what you suggest.
Thanks for your suggestion.
s
Rather than have to define the line properties in each script, I found
that there's a macros mechanism available.
In .gnuplot, I defined a number of macros like the following:
XYZ=" title \'xyz\' with lines lt rgb \'brown\' lw 3"
Then in the gnuplot script, do the following:
set macros ;
and then plot your graph calling the macro as follows:
'file' using 1:3 @XYZ
Hope this helps.
Yes, but this feature was added only recently, and only applies
to version 4.1
>
>In .gnuplot, I defined a number of macros like the following:
>
>XYZ=" title \'xyz\' with lines lt rgb \'brown\' lw 3"
>
>Then in the gnuplot script, do the following:
>
>set macros ;
>
>and then plot your graph calling the macro as follows:
>
>'file' using 1:3 @XYZ
>
>Hope this helps.
>
--
Ethan A Merritt
>I had a similar problem. I have a number of scripts that auto-gen
> graphs, each graph has ~15 lines and each line has a specific
> line type/style/title.
Thanks for sharing.
It would be a nice feature to have to make allow the user to redefine the
defaults and leave their main plotting comands the same. Make the
line/points defintions orthogonal to plotting commands.
-s
Yup. It's on my wishlist also. My idea is to have a toggle that
sets the rotation of line choices to either cycle through
successive "linetypes" (current behaviour) or cycle instead through
successive "linestyles" (as defined by "set style line <tag>").
But it's not very high on my priority list. If someone else wants
to work on coding it, go right ahead.
--
Ethan A Merritt