From: Alan W. Irwin <firstname.lastname@example.org>
To: phil rosenberg <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>
Sent: Thursday, 19 January 2012, 19:22
Subject: Re: [Plplot-devel] [ plplot-Bugs-3474186 ] wxWidgets dc and gc driver on
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
Could you send a patch to fix that in all places other than where the
background is set?
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).