octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.9.10, finally?


From: John W. Eaton
Subject: Re: 2.9.10, finally?
Date: Wed, 21 Mar 2007 19:22:45 -0400

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.

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.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]