Multicolor mesh plot patch

"John W. Eaton" <[email protected]> Mon, 26 Sep 2005 18:18:02 -0400
Newsgroups gmane.comp.gnu.octave.graphics,gmane.comp.gnu.octave.bugs
Message-ID <[email protected]>
On 26-Sep-2005, Quentin Spencer wrote:

| I'm not sure which list is best for this, so I'm sending it to bug and 
| graphics. Someone recently was complaining about the quality of mesh 
| plots, and I agree the two-color plots don't look that great. I 
| discovered that this can be changed quite easily using gnuplot 4.0 
| 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.

It would be nice to be able to control the colors, but I wouldn't
worry about that just now.  Fixing this problem probably means that we
want to get some kind of handle graphics capability in Octave soon so
that controlling these kinds of things will be simpler.

| One thing that's missing is a check for whether 
| the "palette" line type is valid. The octave-forge functions surf and 
| surfc use a global gnuplot_has_pm3d, but it's a bit of a hack and I 
| doubt John wants stuff like this in core Octave code. Is there any way 
| to verify the capabilities of gnuplot from octave? We have things like 
| OCTAVE_VERSION and OCTAVE_FORGE_VERSION defined, would it make sense to 
| define GNUPLOT_VERSION?

I'd rather avoid a check on the gnuplot version number.  What if "set
palette" goes away at some point?  Better to use an autoconf check.
There are a couple of examples of how to do this in the aclocal.m4
file.  But do we really need a check?  For 2.9.x at least, I think it
is safe to assume gnuplot 4.x features.

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.

jwe