on 11/17/06 10:58 AM, John W. Eaton at address@hidden wrote:
> In the last week or so I've been working on the existing graphics
> functions in Octave, trying to make things like
>
> legend
> print for multiplot
> images with gnuplot
> plotting on top of images
> eliminating temporary files for plot data
>
> etc. work properly. To do these things, I've been pushing more plot
> data into a set of global variables. For example, the legend command
> now just stores the legend info in a global data structure and the
> gnuplot commands for plotting are regenerated each time replot is
> called.
>
> I thought I was making progress, but unfortunately there are some
> killer problems, especially with multiplot. For example, to make
> printing for multiplot work, I modified things so that the subplot
> function doesn't send "set multiplot" to gnuplot, but instead sets a
> flag in a data structure saying that the current figure is a
> multiplot. Then print can call
>
> __render_plot__ (terminal, output);
>
> and __render_plot__ will
>
> temporarily reset the terminal type and output file
> set multiplot mode
> run through all the plotting commands
> unset multiplot mode
> restore the terminal and output.
>
> This (sort of) works, but to be fully functional, we have to save
> *everything* about the plot, because anything that happens before the
> "set multiplot" will not work properly. Commands sent directly to
> gnuplot while building the plot on the screen and before calling print
> will have unpredictable results.
>
> I can keep moving down the current path of moving more things to the
> global data structures that are in place now, but since it all seems
> like a bad kluge, I think this path is a dead end. So do we want
> Octave 3.0 to still have the bugs with printing, a kluge for legend, no
> ability to plot on top of images, temporary data files for plot data,
> etc.? If not, then I think now is the time to switch to the object
> graphics implementation.
>
> I'm not expecting that all graphics properties or features will be
> implemented before 3.0. All we need is enough to handle the
> capabilities of the current higher-level plotting commands in Octave.
> I think that adding more capabilities will not be that hard, and it
> can be done incrementally as the features are needed.
>
> It is also OK with me if arbitrarily mixing calls to __gnuplot_raw__
> and the higher level plotting commands fails, because we've been slowly
> moving in that direction anyway with the renaming of the gnuplot-style
> commands to be underscored internal commands names. Until we have a
> fairly complete set of object graphics properties available, we will
> just have to tell people that if they want full control over graphics,
> they will need to write their data to a file and use their favorite
> plotting package to generate the plots. This has really always been
> the case. It's unfortunate that Octave ever had the gplot and gset
> commands that made it appear that complete control over gnuplot was
> possible (it never was).
>
> Comments?
>
> jwe
John, et al,
Not being a developer, but really a researcher and data analyst with some
programming background (mostly Fortran), I have some recent experience and
thoughts that may be relevant to the current graphics discussion.
First, I have been working with the gnuplot-beta list to build the new wxt
terminal for gnuplot on my Mac with OS X 10.4.8. The wxt terminal is based
on wxWidgets, pango, and cairo, and, when operational, will be computer
independent for Linux, Windows and Macs. This would eliminate the need for
X11 or AquaTerm on the Mac. The good news is that wxt builds and works
correctly on my Mac. I can see the plots on the screen, and they look good.
The bad news is that unless the application is "bundled" according to Apple
rules, "focus" on the plot window is not possible, so the controls in the
plot window can't be accessed for saving the plot, etc. We have made one
bundling attempt, but after completing the bundle, we still could not get
focus. This is a work in progress, but, if successful, would eliminate the
need for a separate package like AquaTerm or X11 to run gnuplot on Macs. The
implication is that for Macs, a separate "bundled" gnuplot would be
required, but that would probably come with an easy-to-use disk image (.dmg)
installer that even a freshman engineering student could use. A Mac
developer could really help with this effort right now, if one is known.
(Per Persson, the AquaTerm developer, has been consulting, but doesn't have
the time to help, right now.)
I understand John's dilemma with gnuplot, and agree that it is not perfect,
but so much time and effort has gone into the octave/gnuplot interface, that
maybe the temporary solution is to just put some warning messages where the
problems are likely occur. A while back I was converting a MATLAB script
where different parts of a multiplot were done at different points in the
code with other single frame plots interspersed. To do that with gnuplot
would probably require having multiple copies (threads?) of gnuplot working.
Getting that to work seamlessly on Linux, Mac and Windows would probably be
a big challenge. Again, I'm not a developer.
My preference, for the time being anyway, is to keep chugging along with
gnuplot, and continue to investigate options. The gnuplot community seems to
be rejuvenated, so maybe they would have some suggestions, too. (They're
already talking about what will be in gnuplot-4.3, for example.)
One last thought. My current octave hacks allow me to set figure number and
font type with octave/gnuplot/aquaterm. I am hesitant to upgrade octave
because all my data analysis routines work and display properly with 2.9.9
and the 2.9.6 octave-forge. For multiplots, I use the aquaterm ability to
save .eps or .pdf plots. I don't mind minor reworks, but elimination of
those possible hacks in figure.m would make me think twice about upgrading
octave for a while.