matplotlib-users Mailing List for matplotlib

Hi all,
I'm successfully getting all the MPL data files into spy2exe with:
DATA_FILES = matplotlib.get_py2exe_datafiles()
The problem is that that dumps a LOT of stuff, and I don't need most of 
it. I've already added to my script a few lines that delete the "images" 
dir, but I'd like to trim down the fonts to just those I need.
I'm using the wxAgg back-end, with all default fonts -- does anyone know 
which those are?
MPL version: 0.91.2 on Windows (duh!)
by the way, is there any way to dump that data into the exe itself, 
rather than requiring it to be carried alongside?
This makes me really appreciate application bundles on the Mac!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi Mike,
Your test pdf shows up properly in Foxit.
MD> So --- this would appear to be a bug in Foxit. Perhaps you could
MD> submit this problematic PDF to them.
I will do so, and I'll also include your description of the problem.
-- 
Chris

Thanks. Try again now. Hopefully it's correct this time (your test is 
a much better unit test than the animation_blit_* examples.
Cheers,
Mike
Darren Dale wrote:
> I'm testing it out on 64-bit linux with this script:
>
> from pylab import *
> from matplotlib.widgets import Cursor
>
> ax=axes()
> cursor = Cursor(ax, useblit=True)
> ax.imshow(array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]), cmap=cm.jet, 
> interpolation='nearest')
> show()
>
> When the mouse pointer enters the axes, the cursor is drawn, blitting occurs, 
> along with wierdness. I'm attaching screenshots, one using the new 
> to_string_argb and one using to_string.
>
> Darren
>
>
>
>
> On Tuesday 06 May 2008 11:43:50 am Michael Droettboom wrote:
> 
>> This is now implemented on the branch and the trunk. Please let me know
>> how it works for you. I'm particularly interested in non-Linux and Big
>> Endian platforms (e.g. PPC) as a sanity check.
>>
>> Cheers,
>> Mike
>>
>> Michael Droettboom wrote:
>> 
>>> I'll go ahead and fix this. It just fell through the cracks.
>>>
>>> Mike
>>>
>>> Darren Dale wrote:
>>> 
>>>> On Monday 05 May 2008 09:24:42 pm G Jones wrote:
>>>> 
>>>>> Hello,
>>>>> Attached is a script that when run from ipython --pylab with your
>>>>> backend setup for 'QtAgg' reproduces a bug I am seeing. If you run the
>>>>> plot, you'll see a line plotted in blue as expected. Then when the
>>>>> same figure is updated by blitting, the line turns red. I tried this
>>>>> with green and it stayed green, but yellow went to cyan. It seems that
>>>>> the byteswapping that is necessary for displaying colors correctly in
>>>>> Qt is happening during a normal plot, but not when blitting. I tried
>>>>> going through the code to determine the problem, I can only guess that
>>>>> it lies somewhere in the FigureCanvasQTAgg.paintEvent, since that's
>>>>> where I see to_ARGB etc.
>>>>> Sorry I couldn't locate the bug precisely, I find it very difficult to
>>>>> thread my way through all the backend classes.
>>>>> 
>>>> I did track down the source of the bug a while back:
>>>> http://sourceforge.net/mailarchive/message.php?msg_id=200803121528.30565
>>>> .darren.dale%40cornell.edu
>>>>
>>>> Mike D. suggested that BufferRegion might need a byte-swapped version of
>>>> to_string(), but unfortunately I am not an experienced c programmer and
>>>> am short of time to try to work my way through it right now. I added a
>>>> bug report at SF.
>>>>
>>>> Darren
>>>> 
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi
I am attempting to generate graphs using matplotlib/pyplot via a cron 
process. These scripts work perfectly fine when I am logged in and run 
the scripts on the command line, however they fail to run when they are 
set up as a cronjob. Even a simplified plotting routine does not work:
from matplotlib.pylab import plot
from matplotlib.pylab import savefig
plot([1,2,3,4])
savefig('test.png')
my crontab is configured like this:
SHELL= /bin/tcsh
45 8 * * * cd [path to script]; python graphtest.py
Thanks in advance,
-- 
Andre Wong
Gemini North Data Analyst
aw...@ge...
(808) 974 2626

On Tue, May 6, 2008 at 11:17 AM, Matthew Czesarski
<mat...@gm...> wrote:
> So I'm pretty successful so far. The only problem is that the coordinates
> are in canvas coordinates, not plot coordinates. Now, rather embarrassingly,
> I can't figure out how to get this right. It seems to be the case that all
> the examples are in plot coordinates. As of course is the readout in the
> GUI itself. Is there a simple way to fix this or do I have convert it to
> some other backend? Or use something else instead of FigureCanvasGTK? This,
> to me, made the most sense to me at the time of writing, although I must
> confess I'm still pretty new to this.
Use mpl events -- they work across user interface toolkits and handle
stuff like which axes did you click in and what are the data
coordinates
def onclick(event):
 print 'axes', event.inaxes
 if event.inaxes is None: return
 print 'canvas', event.x, event.y
 print 'data', event.xdata, event.ydata
cid = fig.canvas.mpl_connect('button_press_event', onclick)
See matplotlib.backend_bases.Event and derived classes for details on
available attributes. See
matplotlib.backend_bases.FigureCanvasBase.mpl_connect for details on
valid signals,

I'm testing it out on 64-bit linux with this script:
from pylab import *
from matplotlib.widgets import Cursor
ax=axes()
cursor = Cursor(ax, useblit=True)
ax.imshow(array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]), cmap=cm.jet, 
interpolation='nearest')
show()
When the mouse pointer enters the axes, the cursor is drawn, blitting occurs, 
along with wierdness. I'm attaching screenshots, one using the new 
to_string_argb and one using to_string.
Darren
On Tuesday 06 May 2008 11:43:50 am Michael Droettboom wrote:
> This is now implemented on the branch and the trunk. Please let me know
> how it works for you. I'm particularly interested in non-Linux and Big
> Endian platforms (e.g. PPC) as a sanity check.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
> > I'll go ahead and fix this. It just fell through the cracks.
> >
> > Mike
> >
> > Darren Dale wrote:
> >> On Monday 05 May 2008 09:24:42 pm G Jones wrote:
> >>> Hello,
> >>> Attached is a script that when run from ipython --pylab with your
> >>> backend setup for 'QtAgg' reproduces a bug I am seeing. If you run the
> >>> plot, you'll see a line plotted in blue as expected. Then when the
> >>> same figure is updated by blitting, the line turns red. I tried this
> >>> with green and it stayed green, but yellow went to cyan. It seems that
> >>> the byteswapping that is necessary for displaying colors correctly in
> >>> Qt is happening during a normal plot, but not when blitting. I tried
> >>> going through the code to determine the problem, I can only guess that
> >>> it lies somewhere in the FigureCanvasQTAgg.paintEvent, since that's
> >>> where I see to_ARGB etc.
> >>> Sorry I couldn't locate the bug precisely, I find it very difficult to
> >>> thread my way through all the backend classes.
> >>
> >> I did track down the source of the bug a while back:
> >> http://sourceforge.net/mailarchive/message.php?msg_id=200803121528.30565
> >>.darren.dale%40cornell.edu
> >>
> >> Mike D. suggested that BufferRegion might need a byte-swapped version of
> >> to_string(), but unfortunately I am not an experienced c programmer and
> >> am short of time to try to work my way through it right now. I added a
> >> bug report at SF.
> >>
> >> Darren

I would like to be able to draw a triangle on the graph outside the axes and
plot area. I have used fill before, but that was in the plot area. Can
someone push me in the right direction?
-- 
"The game of science can accurately be described as a never-ending insult to
human intelligence." - João Magueijo

That's a good one!
Here's what I see happening: By default (without manually specifying 
zorder), all Collections are drawn before all Lines. In an errorbar, 
the data itself and the caps are both drawn using Lines, but the 
errorbar is drawn using a LineCollection. So what you're seeing is a 
strange interleaving of different parts of the errorbar plot.
By forcing zorder on these things, you can get the artists associated 
with each errorbar call to render together in the overall ordering -->
errorbar([1,2,3],[3,3,3],color='black',mfc='white',marker='s',ms=14,zorder=10)
errorbar([1,2,3],[2,2,2],[1,1,1],color='black',zorder=20)
Unfortunately, it's a messy, non-obvious workaround.
IMHO, the way the default zorder works is probably due for an overhaul, 
but it's a pretty core thing to be messing with and risks breaking a lot 
of existing plots. For example, I've never quite understood why all 
collections are drawn before all lines (and exist in separate artist 
lists), rather than just interleaving them as they are added to the 
plot. But I wasn't around to see that develop, so I may just 
misunderstand. And I don't really have the time to do this now, so I 
should probably keep quiet ;)
Cheers,
Mike
Christopher Brown wrote:
> Hi mpl users,
>
> I have noticed that when making a figure using the errorbar function, a 
> cap line will show up over a marker if they happen to fall on top of one 
> another. The line connecting the caps is (properly) hidden under the 
> marker. This behavior only occurs if the overlapping marker was placed 
> on the plot before the overlapping errorbar.
>
> The following code demonstrates the problem:
>
> errorbar([1,2,3],[3,3,3],color='black',mfc='white',marker='s',ms=14)
> errorbar([1,2,3],[2,2,2],[1,1,1],color='black')
> ylim(0,4)
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

In matplotlib's Python PDF backend, each marker type is stored in an 
XObject (a reusable object) only once, and referenced to draw each to 
the screen. The Cairo backend does not have this optimization and draws 
each marker independently. It would seem that Foxit does not use the 
current graphics context (pen width etc.) when referencing XObjects.
The PDF Spec (version 1.7) has this to say (emphasis mine):
 A form XObject is a PDF content stream that is a self-contained
 description of any sequence of graphics objects (including path
 objects, text objects, and sampled images). A form XObject may be
 painted multiple times—either on several pages or at several
 locations on the same page—and produces the same results each time,
 /subject only to the graphics state at the time it is invoked/. Not
 only is this shared definition economical to represent in the PDF
 file, but under suitable circumstances the PDF consumer application
 can optimize execution by caching the results of rendering the form
 XObject for repeated reuse.
So --- this would appear to be a bug in Foxit. Perhaps you could submit 
this problematic PDF to them.
We could fairly easily provide a workaround by not doing this 
optimization (I've attached a PDF so you can verify that it solves the 
Foxit issue). But it is an important optimization when there are 
hundreds of markers in a plot. We could make this user-configurable, but 
I'm wary of adding more config parameters without really good reasons -- 
many user issues on this list come down to someone using a particular 
configuration that a developer neglected to test with.
What do others here think?
Cheers,
Mike
Christopher Brown wrote:
> Hi Michael,
>
> MD> I can't be of much help with Windows builds, unfortunately.
> MD> However, for clarification, is this error from building pycairo or
> MD> matplotlib? matplotlib *should* be able to bypass pkg-config if it
> MD> isn't available.
>
> The error occurred while building pycairo.
>
> MD> > will create a figure tonight from home (kubuntu) using the cairo
> MD> > backend, then examine it tomorrow at work (windows/foxit) and
> MD> > report back.
> MD> >
> MD> Sounds like a good experiment. Thanks for helping out.
>
> With a plot made using the cairo backend, the markers render correctly 
> in foxit. I am standing by for further instruction. :)
>
> By the way, I'm using mpl from svn.
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi mpl users,
I have noticed that when making a figure using the errorbar function, a 
cap line will show up over a marker if they happen to fall on top of one 
another. The line connecting the caps is (properly) hidden under the 
marker. This behavior only occurs if the overlapping marker was placed 
on the plot before the overlapping errorbar.
The following code demonstrates the problem:
errorbar([1,2,3],[3,3,3],color='black',mfc='white',marker='s',ms=14)
errorbar([1,2,3],[2,2,2],[1,1,1],color='black')
ylim(0,4)
-- 
Chris

Dear Group,
What I need to do is to
1. produce a plot (DONE)
2. fix it so that mouse clicks in the canvas append the x coordinate of the
click to a list (DONE)
3. add a couple of buttons to the GUI, to reset the list and to kill the
window (DONE)
So I'm pretty successful so far. The only problem is that the coordinates
are in canvas coordinates, not plot coordinates. Now, rather embarrassingly,
I can't figure out how to get this right. It seems to be the case that all
the examples are in plot coordinates. As of course is the readout in the
GUI itself. Is there a simple way to fix this or do I have convert it to
some other backend? Or use something else instead of FigureCanvasGTK? This,
to me, made the most sense to me at the time of writing, although I must
confess I'm still pretty new to this.
I paste some stripped down code below.
Thanks in advance,
Matthew
#!/usr/bin/env python
import sys, os, string
import scipy as S
pygtk.require('2.0')
import gtk
#MPL.use('GTKAgg')
import pylab as P
from matplotlib.backends.backend_gtk import FigureCanvasGTK as FigureCanvas
from matplotlib.backends.backend_gtk import NavigationToolbar2GTK as
NavigationToolbar
class Stuff:
 def reset(self, widget, data=None):
 self.ranges= S.array([])
 print self.ranges
 def delete_event(self, widget, event, data=None):
 print "delete event occurred"
 return False
 def destroy(self, widget, data=None):
 gtk.main_quit()
 def clickCanvas(self, widget, event):
 if event.button==1:
 self.ranges = S.append(self.ranges , event.x)
 print self.ranges
 def ZoneSetup(self):
 x=S.rand(10)
 y=S.rand(10)
 win = gtk.Window()
 win.connect("delete_event", self.delete_event)
 win.connect("destroy", self.destroy)
 win.set_default_size(600,450)
 vbox = gtk.VBox()
 hbox = gtk.HBox()
 win.add(vbox)
 fig = P.Figure(figsize=(5,4), dpi=100)
 ax = fig.add_subplot(111)
 ax.plot(x, y, c='red', ls='-')
 canvas = FigureCanvas(fig)
 vbox.pack_start(canvas)
 toolbar = NavigationToolbar(canvas, win)
 hbox.pack_start(toolbar)
 bReset = gtk.Button("Reset")
 bQuit = gtk.Button("Quit")
 hbox.pack_start(bReset, False, False, 0)
 hbox.pack_start(bQuit, False, False, 0)
 vbox.pack_start(hbox, False, False)
 bReset.connect ("clicked", self.reset)
 bQuit.connect_object("clicked", gtk.Widget.destroy, win)
 canvas.connect("button_press_event", self.clickCanvas)
 win.show_all()
 gtk.main()
 def __init__(self):
 self.ranges= S.array([])
a=Stuff()
a.ZoneSetup()
print a.ranges

Hi all,
How is it possible to display by default the minor ticks with an 
interval 5 times
smaller than the major ticks.
I can do that for a known range of data : for example :
ax = pt.gca()
ax.xaxis.set_major_locator(MultipleLocator(10))
ax.xaxis.set_minor_locator(MultipleLocator(10/5.))
but I would like to have the major still set by default, i.e. :
ax.xaxis.set_major_locator(AutoLocator())
and now the minor automatically set to 1/5. of the value used for the major.
How can I do that ?
Thanks for your help,
yves
-- 
 (o o)
--------------------------------------------oOO--(_)--OOo-------
 Yves Revaz
 Laboratory of Astrophysics EPFL
 Observatoire de Sauverny Tel : ++ 41 22 379 24 28
 51. Ch. des Maillettes Fax : ++ 41 22 379 22 05
 1290 Sauverny e-mail : Yve...@ep...
 SWITZERLAND Web : http://www.lunix.ch/revaz/
----------------------------------------------------------------

Hi Michael,
MD> I can't be of much help with Windows builds, unfortunately.
MD> However, for clarification, is this error from building pycairo or
MD> matplotlib? matplotlib *should* be able to bypass pkg-config if it
MD> isn't available.
The error occurred while building pycairo.
MD> > will create a figure tonight from home (kubuntu) using the cairo
MD> > backend, then examine it tomorrow at work (windows/foxit) and
MD> > report back.
MD> >
MD> Sounds like a good experiment. Thanks for helping out.
With a plot made using the cairo backend, the markers render correctly 
in foxit. I am standing by for further instruction. :)
By the way, I'm using mpl from svn.
-- 
Chris

This is now implemented on the branch and the trunk. Please let me know 
how it works for you. I'm particularly interested in non-Linux and Big 
Endian platforms (e.g. PPC) as a sanity check.
Cheers,
Mike
Michael Droettboom wrote:
> I'll go ahead and fix this. It just fell through the cracks.
>
> Mike
>
> Darren Dale wrote:
> 
>> On Monday 05 May 2008 09:24:42 pm G Jones wrote:
>> 
>> 
>>> Hello,
>>> Attached is a script that when run from ipython --pylab with your
>>> backend setup for 'QtAgg' reproduces a bug I am seeing. If you run the
>>> plot, you'll see a line plotted in blue as expected. Then when the
>>> same figure is updated by blitting, the line turns red. I tried this
>>> with green and it stayed green, but yellow went to cyan. It seems that
>>> the byteswapping that is necessary for displaying colors correctly in
>>> Qt is happening during a normal plot, but not when blitting. I tried
>>> going through the code to determine the problem, I can only guess that
>>> it lies somewhere in the FigureCanvasQTAgg.paintEvent, since that's
>>> where I see to_ARGB etc.
>>> Sorry I couldn't locate the bug precisely, I find it very difficult to
>>> thread my way through all the backend classes.
>>> 
>>> 
>> I did track down the source of the bug a while back: 
>> http://sourceforge.net/mailarchive/message.php?msg_id=200803121528.30565.darren.dale%40cornell.edu
>>
>> Mike D. suggested that BufferRegion might need a byte-swapped version of 
>> to_string(), but unfortunately I am not an experienced c programmer and am 
>> short of time to try to work my way through it right now. I added a bug 
>> report at SF.
>>
>> Darren
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>> Don't miss this year's exciting event. There's still time to save 100ドル. 
>> Use priority code J8TL2D2. 
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, May 6, 2008 at 9:33 AM, Fabrice Silva <si...@lm...> wrote:
> Contrary to what the on-line doc says, the set_xticks method of an axes
> instance does not have the 'minor' keyword argument...
>
>
> S1.set_xticks(Xticksm, minor=True)
> TypeError: set_xticks() got an unexpected keyword argument 'minor'
>
>
> __version__ = '0.90.1'
> __revision__ = '$Revision: 3333 $'
> __date__ = '$Date: 2007年05月31日 09:52:25 -0400 (2007年5月31日) $'
This works for me -- I wonder if your version is out of date. 0.90.1
is pretty old
In [7]: ax.set_xticks([1.1,1.2,1.3], minor=True)
Out[7]:
[<matplotlib.axis.XTick instance at 0x817418c>,
 <matplotlib.axis.XTick instance at 0x8f318ec>,
 <matplotlib.axis.XTick instance at 0x8f319cc>]
In [8]: draw()
In [9]: matplotlib.__version__
Out[9]: '0.91.2svn'
JDH
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save 100ドル.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Contrary to what the on-line doc says, the set_xticks method of an axes
instance does not have the 'minor' keyword argument...
 S1.set_xticks(Xticksm, minor=True)
TypeError: set_xticks() got an unexpected keyword argument 'minor'
__version__ = '0.90.1'
__revision__ = '$Revision: 3333 $'
__date__ = '$Date: 2007年05月31日 09:52:25 -0400 (2007年5月31日) $'

I'll go ahead and fix this. It just fell through the cracks.
Mike
Darren Dale wrote:
> On Monday 05 May 2008 09:24:42 pm G Jones wrote:
> 
>> Hello,
>> Attached is a script that when run from ipython --pylab with your
>> backend setup for 'QtAgg' reproduces a bug I am seeing. If you run the
>> plot, you'll see a line plotted in blue as expected. Then when the
>> same figure is updated by blitting, the line turns red. I tried this
>> with green and it stayed green, but yellow went to cyan. It seems that
>> the byteswapping that is necessary for displaying colors correctly in
>> Qt is happening during a normal plot, but not when blitting. I tried
>> going through the code to determine the problem, I can only guess that
>> it lies somewhere in the FigureCanvasQTAgg.paintEvent, since that's
>> where I see to_ARGB etc.
>> Sorry I couldn't locate the bug precisely, I find it very difficult to
>> thread my way through all the backend classes.
>> 
>
> I did track down the source of the bug a while back: 
> http://sourceforge.net/mailarchive/message.php?msg_id=200803121528.30565.darren.dale%40cornell.edu
>
> Mike D. suggested that BufferRegion might need a byte-swapped version of 
> to_string(), but unfortunately I am not an experienced c programmer and am 
> short of time to try to work my way through it right now. I added a bug 
> report at SF.
>
> Darren
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Monday 05 May 2008 09:24:42 pm G Jones wrote:
> Hello,
> Attached is a script that when run from ipython --pylab with your
> backend setup for 'QtAgg' reproduces a bug I am seeing. If you run the
> plot, you'll see a line plotted in blue as expected. Then when the
> same figure is updated by blitting, the line turns red. I tried this
> with green and it stayed green, but yellow went to cyan. It seems that
> the byteswapping that is necessary for displaying colors correctly in
> Qt is happening during a normal plot, but not when blitting. I tried
> going through the code to determine the problem, I can only guess that
> it lies somewhere in the FigureCanvasQTAgg.paintEvent, since that's
> where I see to_ARGB etc.
> Sorry I couldn't locate the bug precisely, I find it very difficult to
> thread my way through all the backend classes.
I did track down the source of the bug a while back: 
http://sourceforge.net/mailarchive/message.php?msg_id=200803121528.30565.darren.dale%40cornell.edu
Mike D. suggested that BufferRegion might need a byte-swapped version of 
to_string(), but unfortunately I am not an experienced c programmer and am 
short of time to try to work my way through it right now. I added a bug 
report at SF.
Darren

Christopher Brown wrote:
> Hi Mike,
>
> MD> It's worth noting -- these viewer differences do pop up from time to
> MD> time. Since I don't have Foxit (or Windows) installed, I wonder if
> MD> you could run an experiment. If you generate the PDF with mpl's
> MD> Cairo backend, do you see the same behavior? If not, we can
> MD> analyse the differences in the PDFs and possibly come up with a
> MD> solution that will work.
>
> I'm having real difficulty getting the cairo backend installed. If
> anyone has any experience with pkg-config and windows, please let me
> know. Specifically, I get the error:
>
> Package 'cairo was not found in the pkg-config search path. Perhaps you
> should add the directory containing `'cairo.pc' to the PKG_CONFIG_PATH
> environment variable
>
> ...although I have, in fact, created this environment variable in windows.
> 
I can't be of much help with Windows builds, unfortunately. However, 
for clarification, is this error from building pycairo or matplotlib? 
matplotlib *should* be able to bypass pkg-config if it isn't available.
> Anyway, I have created a pdf using the wxagg backend, which yields the 
> same result (markeredgewidth is always 1 when viewing with foxit). 
That uses the same PDF code path, so not surprising.
> I 
> will create a figure tonight from home (kubuntu) using the cairo 
> backend, then examine it tomorrow at work (windows/foxit) and report back.
>
> 
Sounds like a good experiment. Thanks for helping out.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello,
Attached is a script that when run from ipython --pylab with your
backend setup for 'QtAgg' reproduces a bug I am seeing. If you run the
plot, you'll see a line plotted in blue as expected. Then when the
same figure is updated by blitting, the line turns red. I tried this
with green and it stayed green, but yellow went to cyan. It seems that
the byteswapping that is necessary for displaying colors correctly in
Qt is happening during a normal plot, but not when blitting. I tried
going through the code to determine the problem, I can only guess that
it lies somewhere in the FigureCanvasQTAgg.paintEvent, since that's
where I see to_ARGB etc.
Sorry I couldn't locate the bug precisely, I find it very difficult to
thread my way through all the backend classes.
Glenn