Here is some background to help all of us figure out what is going on. The
-cmap0 option is parsed and executed when plparseopts is executed. If that
command-line option is not specified, then plinit calls plstrm_init which
calls plspal0("") (for the case when plsc->cmap0 == NULL) which has exactly
the same effect (default colours) as the -cmap0 "" option. So we should
never get bad cmap0 colours unless plsc->cmap0 != NULL, i.e., some other
method has been used to initialize colours.
The previous version of the cmap0 initialization used a call to plscmap0n(0)
rather than plspal0(""). The old version of plscmap0n(0) would give you
default cmap0 colours under certain circumstances, but now it just gives you
red colours (see revision 10315 where I changed the identification but not
the rgb values appropriately to "red" from "black") as a warning that the
colours have not been initialized properly.
Following up on this, I tried running plscmap0n(0) before plinit in example
10 for the python case (note not Ada), and sure enough I got an all-red
result. Some of our users must be depending on the old cmap0 initialization
behaviour (plscmap0n(0) setting default colours if called before plinit) so
that past behaviour should be restored.
Hez, could you do that by inserting a call to plspal0("") into plscmap0n for
the case when it is appropriate (plsc->cmap0 == NULL)? N.B. I am
specifically not asking for a return to all the specific hard-coded colours
implemented with color_def that we had before since I far prefer the colour
palette file approach. Of course, the tricky part of implementing this with
colour palette files is to avoid infinitely recursive behaviour (since
plscmap0n(0) is called by plspal0). That is why I am asking someone more
expert than me in C to deal with this. :-)
Once plscmap0n(0) gives default colours like before, I suspect all the Ada
red issues will go away. Jerry has remarked before that our Ada bindings do
their own colour initialization, and my guess is that boils down in the
cmap0 case to a call to plscmap0n(0).
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
