Re: Multicolor mesh plot patch

> | features. The attached patch makes mesh use color lines. It also defines
> | a color palette that is very similar to Matlab's default palette. I
> | don't know if this is the best way to do this, I'm open to suggestions
> | on how to improve it.

I propose you let
    __gnuplot_set__ colorbox
instead of nocolorbox ... colorbox is a very useful thing and without it you 
are looking at a "blind" image.

> It would be nice to be able to control the colors, but I wouldn't
> worry about that just now.

This is solved, see  imagegp.m  pointed by Daniel. It copies octave's 
current colormap() into gnuplot.

> | define GNUPLOT_VERSION?
>
> I'd rather avoid a check on the gnuplot version number.
> Better to use an autoconf check.
> For 2.9.x at least, I think it
> is safe to assume gnuplot 4.x features.

The best way is that autoconf refuses to finish octave's configure if 
gnuplot version is below a threshold. I propose that octave's configure 
should require gnuplot 4.0 or higher.


> Also, you should use __gnuplot_raw__ instead of __gnuplot_set__ except
> for
>
>  __gnuplot_set__ parameteric
>  __gnuplot_set__ noparametric
>  __gnuplot_set__ term
>
> because __gnuplot_set__ does some extra processing, but only for these
> settings.

I'd like to say I do not like that the recent Octave removed gset/graw 
commands. Without them, no nice (publication quality) plots can be produced. 
Writing all those long commands __gnuplot_set__ is a big nuisance; to fix 
it, everybody will define his own gset.m/graw.m (or patch out Octave's nag 
message). That's not the goal I think.

I propose that this nag message is printed only if the plotting engine is 
not gnuplot. Otherwise, it should work as until now.

Moving the graphics engine code into a single directory, with an easy switch 
to other plotting engines, would be great. Then the imagegp.m could go there 
as image.m.

---
PM