Re: svg : gnuplot_plot_1

[<pl...@pi...>]

On 10/22/11 17:45, Ethan Merritt wrote:
>      set term foo
>
>      set output 'plot1.foo'
>      set title "Graphs AB"
>      plot "A.dat" title "A", "B.dat" title "B"
>
>      set output 'plot2.foo'
>      set title "Graphs CDE"
>      plot "C.dat", "D.dat", "E.dat"
>
>      ... and so on for many plots
>
> I

There seem to be two ways to satisfy this sort of case:

1. a new global variable like set title , let's call it set doctitle. 
This could be reset without reopening the terminal.

2. use existing gnuplot and reopen the terminal with a new "name". This 
is somewhat of a work around but seems a reasonable one.

When I suggested  a new option to set output I was referring to 
something like 1 , since output is a variable , not an object it can't 
itself have options.

In the case of 1. help would explain that variable only affects some 
terminals (canvas,svg,pdf , etc) and is ignored where it is irrelevant.

2. Presents a compat issue for canvas since this is already out in the 
field. The terminal could default to existing behaviour if both are 
present,


Option 1 would seem to be the most structured solution since, as you 
have pointed out, this is not actually a property of the terminal.


Your code example (with more realistic plot titles) becomes :

       set term foo

       set output 'plot1.foo'
set doctitle "Corell A vs B"
       set title "Correlation ceofficient of quantity A against quantity B"
       plot "A.dat" title "A", "B.dat" title "B"

       set output 'plot2.foo'
set doctitle "Corell C vs DE"
       set title "Correlation ceofficient of quantity C against quantity 
D and E"
       plot "C.dat", "D.dat", "E.dat"



This also addresses the corollary issue that I brought up: the need for 
a visible name to conform to js syntax rules and the resulting untidy 
need for underscores.

terminal "name" would become in effect "js_id" . Its use would not 
compromise visible elements and errors would make more sense. Nothing 
would prevent automated scripts from using the same (js valid) string 
for both if that was desired.

Does the above scheme fit in with your requirements?

It's probably worth making the right choice at this stage since further 
compatibility issues will arise for changes made later, as features get 
into stable releases.



best regards, Peter.