From graphics-request at octave dot org Tue Sep 27 10:01:42 2005 Subject: Re: Multicolor mesh plot patch From: Quentin Spencer To: Petr Mikulik CC: "John W. Eaton" , bug@octave.org, graphics@octave.org Date: Tue, 27 Sep 2005 09:54:28 -0500 Petr Mikulik wrote: >> | 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. The theory behind my doing this was Matlab compatibility--by default Matlab plots have no colorbox, but the command "colorbar" adds one. (For the same reason, I think that by default we should have "set nokey" for all plots, and the "legend" command used to add them). >> 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. They can with the print command (in octave-forge). > 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. I agree it would be nice to use a different image function that uses gnuplot instead of ImageMagick. I once tried doing this with gnuplot 4.0 and found that it can work, but it's painfully slow for larger data sets because of the text file method of data transfer. Once again, we're also facing the problem that imagegp.m apparently requires the non-existent gnuplot 4.1 that may not exist for a while yet because of developer time constraints (understandable) and apparently some stupid licensing constraints (what were they thinking?). -Quentin