I have just added some example plots to my webspace at http://homepages.see.leeds.ac.uk/~earpros/plplottest/
wxWidgets backend 1 also is giving me problems, I have AGG and Freetype, but don't seem to have Freetype set up correctly and it cannot load fonts so causes my program to exit. I presume you realised that when using AGG you need to pass a wxImage not a wxGC?
The only difference between the wxWidgets exaples and the psc example I posted is a change of the used character because i'm using a custom unicode font for my plotting symbols which isn't supported (or I can't work out how to use) in the postscript driver.
You can obviously see that the postscript file has circles with varying colour and the wxWidgets screen grabs have black points from setting the axis/label text.
The problem occurrs because in wxPLDevGC::ProcessString and wxPLDevDC::ProcessString calls are made directly to pls->cmap0[pls->icol0] to get the text colour instead of to pls->curcolor. Although i can't get the AGG backen to run at the moment the source code only includes calls to pls->cmap0 in the wxPLDevAGG::SetColor0 method so I assume the behaviour must be different.
From: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
To: phil rosenberg <philip_rosenberg@yahoo.com>
Cc: "plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
Sent: Thursday, 19 January 2012, 3:12
Subject: Re: [Plplot-devel] [ plplot-Bugs-3474186 ] wxWidgets dc and gc driver on

On 2012-01-18 13:25-0800 phil rosenberg wrote:

> Hi Andrew and Maurice
> I agree that the recommendation is that cmap1 is used for e.g. colourscales of shade plots, and cmap0 be used for points/lines/text,
> but the manual seems to imply this is a recommendation and that whichever map you use to set the colour will be used. The psc driver
> follows the latter behaviour. You may even see it as advantage to be able to set cmap1 colour fror a fill, but then a cmap0 colour for
> text.
> The situation I was in was using plstring to plot points on an x, y scale but I wanted the colour of the points to vary with a third
> variable, z. Example psudocode is below.
> //x, y, z 1d data
> double x[20];
> double y[20];
> double z[20];
> double maxz;//maximum value in the z array
> char pointcharacter[2]; //character used as a datapoint on my plot
> //some code to initialize my data
> //some code to initialize cmap1 using a hls colour scale
> for(int i=0; i<20; i++)
> {
>     plcol1(z[i]/maxz);
>     plstring(1,x+i,y+i,pointcharacter);
> }
> One alternative could be to introduce a function which returns the rgb/hls value of col1, allowing col0 to be set. However I think that
> given the wxWidgets drivers differ in behaviour from the psc driver (and I have a feeling the one of the three wxWidgets drivers
> differs from the others) means that this is a bug and all drivers should behave the same in this respect, whichever way is deamed
> correct.
> Thanks for taking the time to consider this.

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).

Interestingly I get the same colour results for both -dev psc and -dev
wxwidgets (both Basic and wxGC).  I tried the two wxwidgets versions
as follows:

examples/c/x12c -dev wxwidgets -drvopt backend=0
examples/c/x12c -dev wxwidgets -drvopt backend=2

(If I try backend=1 to get the AGG version, I get a segfault
presumably because I don't have the AGG library installed, but our
build system and the wxwidgets code should have jointly figured that
out and cleanly dropped the AGG part of the wxwidgets device driver
without creating a segfault so that is a wxwidgets + build system

Phil, will you try backend=0 and backend=2 to confirm my consistent
colour results with -dev psc for those and confirm that backend=1 has
inconsistent colour? If you confirm, that means we have just
discovered a total of two bugs in the AGG version, the segfault I just
discovered, and the inconsistent colour results with other devices.

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