From graphics-request at octave dot org Mon Sep 26 17:18:19 2005 Subject: Multicolor mesh plot patch From: "John W. Eaton" To: Quentin Spencer Cc: bug at octave dot org, graphics@octave.org Date: Mon, 26 Sep 2005 18:18:02 -0400 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