On 2012-01-18 19:12-0800 Alan W. Irwin wrote: > Just to jump in late here, it is worth looking at what > standard example 12 (examples/c/x12c.c) does. It first plots > a box with default cmap0 colour (red). Then it does the > following two commands: > > plcol0( 2 ); > pllab( "Year", "Widget Sales (millions)", "#frPLplot Example 12" ); > > That first command changes the colour to yellow, and the second plots > those strings in that designated colour. So far, so good. > > Then it goes through a loop which contains calls to plcol1 with > changing argument. Although the loop plot commands include both fills > and text, only the fills seem to be affected by the plcol1 call, _BUT_ > the text comes out as red. I am virtually positive that is a bug > in the core PLplot library. > > I suppose one possibility is the text should be in the current > (yellow) cmap0 colour, but I think behind the scenes the two colour > maps are setting the same ultimate colour in two different ways so I > think what should happen here is the text should also be displayed in > the cmap1 colour in that loop. We need a volunteer to look carefully > at our core colour code to figure this out with a reliable device ( > probably anything but the AGG version of wxwidgets, see below).
Out of curiosity, I looked further into this, and all is well in our basic colour handling. plcol0 and plcol1 are designed to produce equivalent results for text and line colours. >From the code in src/plctrl.c, both plcol0 and plcol1 set plsc->curcolor.[rgba]. Then if you look at well-maintained drivers such as svg.c, it refers exclusively to curcolor.[rgba] except when setting the background colour. For example, when it writes text is does this. Then I looked more closely at example 12, and there is a call to plcol0(1) in plfbox to force the text to be red (which explains that result which was puzzling me). If you temporarily remove that call, then the plcol1 call in the loop controls curcolor, and the result is the text matches the fill colours. That is the expected behaviour, and it some driver doesn't produce text and lines that follow whatever colour is specified by the last call to _either_ plcol0 or plcol1, then it is a driver bug. Phil, I think you have already come to similar conclusions. Having just read through our colour documentation, do you have a suggestion about where we could make the equivalence of plcol0 and plcol1 for setting the colour of text and lines a lot clearer? Also, you apparently spotted a bug in the wxwidgets code where it refers to cmap0 rather than curcolor. I confirm that with the following command that shows there are lots of instances of this bug. software@raven> grep cmap0 drivers/wxwidgets* |wc -l 28 Could you send a patch to fix that in all places other than where the background is set? 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
