[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: desired features for gp backend?
From: |
Ben Abbott |
Subject: |
Re: desired features for gp backend? |
Date: |
Thu, 18 Jun 2009 10:37:36 -0400 |
On Thursday, June 18, 2009, at 09:27AM, "John W. Eaton" <address@hidden> wrote:
>On 17-Jun-2009, Daniel J Sebald wrote:
>
>| John W. Eaton wrote:
>|
>| > I've said many times that I think that trying to implement the gnuplot
>| > syntax in Octave was a big mistake. I wish I had never done it.
>|
>| I'm not sure what the alternative would have been at the time, but
>| that's the route you chose.
>
>The other alternative would have been to completely hide gnuplot
>behind some plotting functions without introducing any new syntax.
>
>| > I have no interest in doing this because it ties your plotting
>| > commands to gnuplot, and introduces portability problems for people
>| > who don't want to use gnuplot for plotting.
>|
>| Sort of, but not really. set(fig, 'postplot', ...) says nothing
>| about what is at the other end.
>
>I've always assumed that you wanted to pass literal gnuplot syntax as
>the postplot property. To me, that ties you to gnuplot. If you mean
>for the postplot property to just be some generic new property that
>could be handled by any plotting engine, then I don't see the point.
>It seems to me that we might as well just improve the existing plot
>properties or introduce specific new properties for features that are
>missing.
>
>| The rule would be that the option
>| is "hidden", i.e., can't be used as valid syntax in any scripts or
>| packages.
>
>What do you mean by that? What does "scripts or packages" mean to
>you? If not in scripts or packages, where would it be used?
>
>| The analogy is the startup file of Octave or other
>| programs; a means to initialize or cleanup the plotting engine.
>
>Then wouldn't
>
> initialize_plotting_engine ()
> cleanup_plotting_engine ();
>
>be all you need, and leave it up to the plotting engine to do its
>magic? Why is a property and corresponding value needed? How can you
>ensure that the value of the "postplot" property is meaningful for
>every possible plotting engine?
>
>jwe
It is not clear to me what aspect of the rendered figure would be changed with
preplot / postplot properties or with initialize_plotting_engine /
cleanup_plotting_engine.
I suspect pre/post figure commands would have limited use. If such were to be
implemented, they would be more useful if they were applied to the axes.
Ben
- Re: desired features for gp backend?,
Ben Abbott <=