graphics crossroads

[John W. Eaton]

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