Re: 2.9.10, finally?

[Daniel J Sebald]

John W. Eaton wrote:
> On 21-Mar-2007, Daniel J Sebald wrote:
>
> | John W. Eaton wrote:
> | > On 21-Mar-2007, Daniel J Sebald wrote:
> | > 
> | > | John W. Eaton wrote:
> | > | 
> | > | >   - It is no longer possible to mix Matlab-style plot commands with
> | > | >     the old (and now really obsolete) style of plot commands
> | > | >     (__gnuplot_set__, etc.).  You can do one or the other, but not
> | > | >     both for the same plot.
> | > | 
> | > | Not true.  In fact, it currently may be the best setup yet.  Consider the following:
> | > | 
> | > | image
> | > | ps = get(gcf,"__plot_stream__")
> | > | fprintf(ps,"unset colorbox\n")
> | > | fprintf(ps,"replot\n")
> | > | fflush(ps)
> | > 
> | > OK, but I'd rather not recommend doing this sort of thing.
> | > 
> | > At the very least, we should tell people that if they do tricky things
> | > like this, then their code will depend explicitly on gnuplot, which
> | > will make it fail for other graphics backends.
> | 
> | Not recommended, but it is a non-portable way of accessing the external graphics 
> | engine and possibly using otherwise unreachable features.  I think that is a 
> | good thing.  Don't have to mention "gnuplot", simply that __gnuplot_set__, etc 
> | are gone.
>
> What is the point of not mentioning gnuplot if you are describing how
> to send gnuplot commands to the plot stream?   It is highly unlikely
> that any other graphics backend will do anything useful with these
> commands even if it happens to use __plot_stream__.  The name
> __plot_stream__ should already indicate that it is a private property
> that could change or disappear at any time.

That's all true, but why is that detrimental?  I wouldn't recommend use of 
__plot_stream__ in documentation.  If all that is said is that __plot_stream__ 
is a non-portable way of accessing the external graphics engine and may change 
in the future, that's only encouraging people who know what they are doing to 
write non-portable code.  Why restrict flexibility for the sake of portability 
when both are possible?


> If you want to access all the features of a particular plotting
> program, then I still think the best advice is to write data to files
> and use the other plotting program directly.

That requires an additional step then.  Say I need to reproduce or tweak a 
graph.  I'd need to rerun Octave to process and save data, then outside Octave 
rerun the graphics commands.  No big deal for one plot.  But many plots is 
another issue.  Furthermore, say it is a simulation with a series of plots in a 
loop.  Rather than just hit return it becomes hit return, go to another window, 
type up key then return key, go back to Octave window, etc.

As far as archiving the code used to produce the plots for a paper or whatnot, 
it's just one set of Octave code, not Octave and the outside graphics engine.

Octave will create temporary, intermediate files if that is all that is wanted 
so no need to worry about cleaning those up.

It saves a little bit here, a little bit there, but that adds up.


Dan