matplotlib-devel Mailing List for matplotlib

Hi Jim,
Would you send me your files? I'm interested in using Qt4 myself.
Thanks,
Darren
On Wednesday 31 May 2006 11:51, James Amundson wrote:
> Hello,
>
> I have ported the existing Qt(3) backend to Qt4. Qt4 is a substantial
> change from Qt3; the Python bindings for Qt have also changed
> substantially. Since the two versions of Qt are likely to coexist for at
> least a while, I think it makes sense to have a separate Qt4 backend.
>
> How do I go about contributing my Qt4 backend? I have three files:
> backend_qt4.py, backend_qt4agg.py and embedding in qt4.py.
>
> Best,
> Jim Amundson
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

Hello,
I have ported the existing Qt(3) backend to Qt4. Qt4 is a substantial
change from Qt3; the Python bindings for Qt have also changed
substantially. Since the two versions of Qt are likely to coexist for at
least a while, I think it makes sense to have a separate Qt4 backend.
How do I go about contributing my Qt4 backend? I have three files:
backend_qt4.py, backend_qt4agg.py and embedding in qt4.py.
Best,
Jim Amundson

Hi everyone,
Here is a script that creates a graph with a y-axis break. I went with a 
suggestion from Darren to use two axes and draw a break symbol in between 
them. The advantage of two axes is that you can pan them independently (plus 
it's probably easier). It shows roughly what I think it should look like, but 
I still have to improve a few things. So I have a few questions:
- how can I hide the y-ticks in the middle of the graph (so hide only the 
ticks on the top y-axis of the lower axes while leaving the ones at the 
bottom there?
- Can I somehow use a transAxes transform so the axis break symbol (now 
implemented as a LineCollection) stays in the same position when panning? Is 
a LineCollection the best choice? I tried with a Patch class, the problem is 
that the verts of this symbol are not connected.
> >>>>> "Ralf" == Ralf Gommers <r.g...@uc...> writes:
>
> Ralf> Hi everyone, Guess no-one has a trick yet to put in an axis
> Ralf> break. My question is now, should this not be on the goals
> Ralf> list at least?
>
> Ralf> If the developers think it is a good idea to implement this,
> Ralf> I would like to have a go at it. As I'm not all that
> Ralf> familiar with the matplotlib internals it would be great if
> Ralf> someone has any ideas on how to go about it.
>
> This is not possible and is not easy. Currently, we don't even have
> independent control of the lines that surround the white axes box (the
> left and right y-axis lines and the upper and lower x-axis lines. It
> is a long-standing wish to be able to control these independently of
> the axes box, and this would be a good place for you to start. See
> axis.py and axes.py.
>
> JDH
Thanks,
Ralf

Jordan,
I committed the quiver patch with a slight modification, no functional change.
Eric
----- Original Message -----
From: Jordan Dawe <jdawe@u.washington.edu>
Date: Tuesday, May 30, 2006 12:39 pm
Subject: [matplotlib-devel] Quiver Patch
To: matplotlib development list <mat...@li...>
> Ok, here's something of a weird patch, because I don't know how to 
> use 
> subversion properly. It has changes to axes.py which update quiver 
> so 
> that it accepts arbitrary X,Y data; it doesn't demand the data be 
> on a 
> grid anymore.
> 
> The other changes are to collections.py; I updated LineCollection 
> so it 
> inherits from ScalarMappable. I did this just by copying what 
> looked 
> like the relevant code from PatchCollection and then I tested it 
> with my 
> LineCollection based version of quiver. I think I got it right, 
> but I 
> don't really know what I'm doing here so someone should check it over.
> 
> Jordan
> 

Jordan,
Sorry for the duplication, but I made and committed a similar LineCollection change before seeing your message. It is almost identical to yours.
I will check your Quiver change and commit it if it looks OK.
Thanks.
Eric
----- Original Message -----
From: Jordan Dawe <jdawe@u.washington.edu>
Date: Tuesday, May 30, 2006 12:39 pm
Subject: [matplotlib-devel] Quiver Patch
To: matplotlib development list <mat...@li...>
> Ok, here's something of a weird patch, because I don't know how to 
> use 
> subversion properly. It has changes to axes.py which update quiver 
> so 
> that it accepts arbitrary X,Y data; it doesn't demand the data be 
> on a 
> grid anymore.
> 
> The other changes are to collections.py; I updated LineCollection 
> so it 
> inherits from ScalarMappable. I did this just by copying what 
> looked 
> like the relevant code from PatchCollection and then I tested it 
> with my 
> LineCollection based version of quiver. I think I got it right, 
> but I 
> don't really know what I'm doing here so someone should check it over.
> 
> Jordan
> 

Ok, here's something of a weird patch, because I don't know how to use 
subversion properly. It has changes to axes.py which update quiver so 
that it accepts arbitrary X,Y data; it doesn't demand the data be on a 
grid anymore.
The other changes are to collections.py; I updated LineCollection so it 
inherits from ScalarMappable. I did this just by copying what looked 
like the relevant code from PatchCollection and then I tested it with my 
LineCollection based version of quiver. I think I got it right, but I 
don't really know what I'm doing here so someone should check it over.
Jordan

John Hunter wrote:
> Hope this helps,
> JDH
> 
Sweet, that helps a lot. Thank you very much.
Jordan

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
 Jordan> Cool, that makes sense. Another question: what plot types
 Jordan> generate 10000 Line2D objects? I can see quiver doing
 Jordan> something like that if one plots an 100x100 grid, but it
 Jordan> seems to me the resulting arrows would be totally
 Jordan> unreadable.
some contours may generate this many line objects. scatters and
pcolors can generate tens of thousands of polygons or more... Never
underestimate the power of the user to throw more stuff into a plot
than previously thought impossible.
 Jordan> Cool, so I take this to mean it would be helpful to add
 Jordan> some code to the __init__() funcs of the collection
 Jordan> objects so they can accept objects as well as vertex data?
 Jordan> Cause I think I could do that.
My weak preference is to have higher level functions that create the
collection objects (think Axes.scatter, Axes.pcolor or many of the
functions in the finance module) rather than overloading the
constructor, which might get confusing. A Collection is at the level
of Line2D -- most users don't create them directly, and helper
functions should make them easy to use.
 Jordan> So, are the basic drawing primitives in matplotlib Line2D,
 Jordan> LineCollection, Patch, and PolyCollection, with QuadMesh a
 Jordan> special case so that pcolor renders fast?
The base types are Text, Line2D, Patch, Image and Collection. Some of
these are specialized, eg TextWithDash inherits from Text, Polygon and
Rectangle inherit from Patch, LineCollection inherits from Collection
and so on. There are several types of Images. There is an artist
hierarchy diagram in the PDF user's guide which is fairly
comprehensive but not entirely up-to-date, eg QuadMesh is not there.
Regarding the design question. I think there is near uniform
consensus that the transforms are kludgy and hard to work with, but as
Andrew has pointed out, it would be a lot of work to replace them with
something more intuitive since they pervade the code; "open heart
surgery on matplotlib", I think he called it. It would have been a good
summer-of-code project. I think it is a reasonably hard problem --
how to support affines plus general non-linear transformations and
have your transformations efficiently updated in the presence of
window resizes and the like. Certainly not a very hard problem --
lots of people have solved it -- but nontrivial. Typically one ends
up special casing the common transformations, so polar plots are
supported with custom axes. One could make a generic axes object that
drew good tick lines and labels in the presence of arbitrary nonlinear
transformations on non-separable axes, but it would take some smarts.
One of the things that makes transformations hard to do well is that
beyond the pure math of affines and functions on those affines, which
is pretty easy, you have to make the results play nicely in the
presence of axes graphs that have tick labels on them in nice places
and user's who want to pan and zoom. What should zoom-to-rect do on a
polar axes? 
I regard the collections as a bit kludgy too -- I had a few specific
use cases I was targeting, basically a few plots types where lots of
objects were being creates: scatters, pcolors, financial candlestick
plots, and tried to find some common denominators. Collections were
the first attempt at solving this problem, and I think I traded too
much flexibility for a somewhat non-intuitive interface and subpar
performance. There is yet room to either refactor the existing
collections or design new ones to solve specific problems better
(think QuadMesh). Whatever their current short-comings, I still think
back fondly to the bad-old-days, when the pcolor_demo advised you to
"go get a cup of coffee" while you waited for it to render. And it
really took that long.
The Axis code needs some improvement, because the notion of each Axes
having a single x-axis and y-axis is fairly limiting, and the ticking
is too slow. Separate objects for each tick line and label slow things
down a lot. 
The Axes code does too much -- handling almost all of the object
creation and the objects these methods return are too primitive (eg
plot, scatter and pcolor are axes methods that return graphics
primitives like Line2D). There is some consensus that we should have
high level plot objects (FunctionItem, ScatterItem, XYPlotItem) which
are created separately from an Axes and contain their primitive
graphics objects. This is closer to the gnuplot model.
Many of the other objects seem to be holding up fairly well and handle
common and unusual cases fairly elegantly -- the FigureCanvas, Figure,
Line2D, Patch, Text and matplotlib Events seem to work pretty well.
Hope this helps,
JDH

> Jordan> Also, a question: why use collection objects? The
> Jordan> implimentation doesn't strike me as being much faster
> Jordan> rendering wise, but maybe I'm wrong. Is it just so all
> Jordan> the objects can be manipulated all at once by changing the
> Jordan> state of the collection? 
>
> collections aren't as fast as they can be, mainly because they use
> sequences of python objects rather than numeric arrays, so all the
> object coercion still has to be done. Their primary efficiency is the
> avoidance of repeated object creation and their attendant function
> calls and setting the graphics contect.
>
> Eg, if you create 10000 Line2D objects, you will pay for 10000 object
> creations, 10000 separate transformations, 10000 calls to the renderer
> draw function, and 10000 settings of the gc state.
> 
Cool, that makes sense. Another question: what plot types generate 
10000 Line2D objects? I can see quiver doing something like that if one 
plots an 100x100 grid, but it seems to me the resulting arrows would be 
totally unreadable.
I hope I'm not coming across as snotty here. I really love matplotlib, 
it's all I use nowadays, and quite an amazing piece of code. I want to 
find someplace where I can start adding functionality, but the backend 
is really confusing me. I guess I'm trying to figure out what bits of 
the code are design decisions and what bits are there because they 
worked, but aren't necessarily the best solution.
> Jordan> Also, is there any particular
> Jordan> reason the collections only accept verts or segments,
> Jordan> instead of being able to just send it a patch or line
> Jordan> object and have the collection object extract the relevant
> Jordan> data?
>
> Currently the collections are designed to be flexible (eg, each polygon can
> have separate color and width properties) and reasonably fast. They
> are not particularly easy to use, so some helper functionality would
> be useful.
> 
Cool, so I take this to mean it would be helpful to add some code to the 
__init__() funcs of the collection objects so they can accept objects as 
well as vertex data? Cause I think I could do that.
So, are the basic drawing primitives in matplotlib Line2D, 
LineCollection, Patch, and PolyCollection, with QuadMesh a special case 
so that pcolor renders fast?
Jordan

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
 Jordan> Also, a question: why use collection objects? The
 Jordan> implimentation doesn't strike me as being much faster
 Jordan> rendering wise, but maybe I'm wrong. Is it just so all
 Jordan> the objects can be manipulated all at once by changing the
 Jordan> state of the collection? 
collections aren't as fast as they can be, mainly because they use
sequences of python objects rather than numeric arrays, so all the
object coercion still has to be done. Their primary efficiency is the
avoidance of repeated object creation and their attendant function
calls and setting the graphics contect.
Eg, if you create 10000 Line2D objects, you will pay for 10000 object
creations, 10000 separate transformations, 10000 calls to the renderer
draw function, and 10000 settings of the gc state.
With a collection, you have a lot less overhead, but they are still
too slow for some purposes.
 Jordan> Also, is there any particular
 Jordan> reason the collections only accept verts or segments,
 Jordan> instead of being able to just send it a patch or line
 Jordan> object and have the collection object extract the relevant
 Jordan> data?
Currently the collections are designed to be flexible (eg, each polygon can
have separate color and width properties) and reasonably fast. They
are not particularly easy to use, so some helper functionality would
be useful.
JDH

Eric Firing wrote:
> Jordan,
>
> Are you sure you want to use a LineCollection for this? If you do, someone is sure to say, "But I want red arrows with black borders..." 
>
> My impression from the earlier posts on this topic was that part of the trouble was an attempt to be too clever and too automatic; this was interfering with getting the transforms right so that the arrows would look right, like text, regardless of how the axes are stretched or squished. Maybe the LineCollection makes this easier, but I am reasonably sure it can be done cleanly and well with PolyCollections also. (I am biased toward the PolyCollection approach because it is closer to the m_vec.m functionality I added to Rich Pawlowicz's m_map; I will need something like this for basemap if it does not already exist.)
>
> Eric
> 
No, I am not sure we want to use LineCollection. I am using it because 
it is harder to see the distortions introduced by data coordinates when 
lines are used instead of polygons. I don't understand the transforms 
and I feel I have zero chance of getting a good looking plot in a 
reasonable length of time working with polygons. So I've been going the 
LineCollection way for two reasons: one, Gary's post with his line arrow 
seemed to indicate he was working in that direction as well (although it 
appears I was hasty to assume that, judging by his follow-up post), and 
two, because I figured I could get something going quickly and then 
build on it. So really, this isn't a transform issue anymore, because 
I've abandoned that idea as beyond my abilities.
If you all feel that turning quiver into line objects isn't a good idea, 
then there's not really much work I can do on it; the polygons work as 
well as they are going to as-is.
Also, a question: why use collection objects? The implimentation 
doesn't strike me as being much faster rendering wise, but maybe I'm 
wrong. Is it just so all the objects can be manipulated all at once by 
changing the state of the collection? Also, is there any particular 
reason the collections only accept verts or segments, instead of being 
able to just send it a patch or line object and have the collection 
object extract the relevant data?
Jordan

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Is there any reason not to simply make LineCollection
 Eric> inherit from ScalarMappable the same way that
 Eric> PatchCollection does? I don't see any real disadvantage or
 Eric> backwards incompatibility, and I think it would be useful
 Eric> and add consistency. I can do it today, barring unforseen
 Eric> problems with related changes I am making.
I think this looks like a good idea too.
JDH

Jordan,
Are you sure you want to use a LineCollection for this? If you do, someone is sure to say, "But I want red arrows with black borders..." 
My impression from the earlier posts on this topic was that part of the trouble was an attempt to be too clever and too automatic; this was interfering with getting the transforms right so that the arrows would look right, like text, regardless of how the axes are stretched or squished. Maybe the LineCollection makes this easier, but I am reasonably sure it can be done cleanly and well with PolyCollections also. (I am biased toward the PolyCollection approach because it is closer to the m_vec.m functionality I added to Rich Pawlowicz's m_map; I will need something like this for basemap if it does not already exist.)
Eric
----- Original Message -----
From: Jordan Dawe <jdawe@u.washington.edu>
Date: Monday, May 29, 2006 7:18 pm
Subject: [matplotlib-devel] Quiver
To: matplotlib development list <mat...@li...>
> Ok, I have some questions about what the protocol for patch 
> submission 
> should be, in terms of 'completeness' of the patch.
> 
> I have a patch for the quiver function that is half done... it has 
> converted the arrows from patches to linecollections, and it will 
> accept 
> arbitrary X and Y coordinates for the arrow positions, as suggested 
> by 
> Rob. Unfortunetly, none of the color functionality is working. 
> Partly 
> this is because the color functionality of LineCollection is 
> different 
> from PolyCollection (which quiver originally used) and partly 
> because I 
> don't understand how matplotlib sets colors at all. Should I 
> submit 
> this half finished patch so that others can have a chance to 
> improve the 
> color function? Or should I not submit until I figure out how 
> color 
> works and fix the thing?
> 
> Furthermore, can LineCollection actually do all the things that 
> quiver's 
> old color commands demand of it? I don't see a place to set a 
> colormap 
> for a LineCollection, but as I said, I don't understand it very well.
> 
> Jordan
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and 
> Risk!Fully trained technicians. The highest number of Red Hat 
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-
> us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

> 
> You can create a line collection that is color mappable by deriving
> from LineCollection and ScalarMappable. It will take a little more
> work to fully integrate it into the colormappable framework, eg so
> colorbars and interactive changing of colormaps works as expected, but
> this may be enough to speed you along
John,
Is there any reason not to simply make LineCollection inherit from ScalarMappable the same way that PatchCollection does? I don't see any real disadvantage or backwards incompatibility, and I think it would be useful and add consistency. I can do it today, barring unforseen problems with related changes I am making.
Eric 

Hello,
No no, it's not a joke, :-).
I was thinking about using matplotlib within a pythonic mozilla plugin
(xulrunner application more precisely).
Using the general and neutral plugin from mozcmgui, I 've succeeded in in=
sert a
GTK Agg canvas in a web page on Linux. It works quite fine, it handles ev=
ents...
I'd like to do the same thing on win32, several possiblities :
- Trying to use gtkAgg, not easy to "branch" a gtk window to an MFC hnwd;
- Trying to use tkAgg, I think it's possible because a tcl/tk plugin exis=
ts for
Windows, but another toolkit is needed (tkinter);
- Trying to use a native "MFCAgg" directly. I'm going to try to "plug" a
win32api windows within a native C++ handle, I wish it's posible.
Why does an MFC(Agg) backend not already exist ? Is it not possible ? Som=
e
licence problems ? Philosophical issues ? Is there any plan to write this=
 some
day ?
Would it be difficult to add such a bachend ?
Furthermore, wouldn't it give a partial answer to interactive session iss=
ues
with pythonwin, scite (MFC based IDE) ?
Thanks a lot,
Cyril.

Hi Jordan,
Thanks for your heads-up. I actually left this and went back to using 
polygon patches for the arrows, mainly because I thought I'd have more 
control over the size without having to do any fancy line collection 
stuff. Re. your change, the call to the LineCollection__init__ function 
in axes.py just needs an extra set of []'s around the list comprehension 
and all is OK, but your solution could work too.
I do intend to look again at the transform stuff to try to get arrows 
transforming properly - just very busy at the moment, but then I usually am.
Gary R.
> I've found one problem with your Arrow LineCollection; it's not actually 
> a line collection. It's one line, so some of the LineCollection 
> functions fail on it. You need to break up the arrow into segments, 
> like this:
> 
> 'barbed': array([ [ [0.,0.], [L,0.] ],
> [ [L,0.], [L-S,S/3] ],
> [ [L,0.], [L-S,-S/3] ] ]
> 
> Except just doing this will break the matrixmultiply. Just a heads-up.
> 
> Jordan

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
 Jordan> Ok, I have some questions about what the protocol for
 Jordan> patch submission should be, in terms of 'completeness' of
 Jordan> the patch.
 Jordan> I have a patch for the quiver function that is half
 Jordan> done... it has converted the arrows from patches to
 Jordan> linecollections, and it will accept arbitrary X and Y
 Jordan> coordinates for the arrow positions, as suggested by Rob.
 Jordan> Unfortunetly, none of the color functionality is working.
 Jordan> Partly this is because the color functionality of
 Jordan> LineCollection is different from PolyCollection (which
 Jordan> quiver originally used) and partly because I don't
 Jordan> understand how matplotlib sets colors at all. Should I
 Jordan> submit this half finished patch so that others can have a
 Jordan> chance to improve the color function? Or should I not
 Jordan> submit until I figure out how color works and fix the
 Jordan> thing?
I don't recommend submitting patches that don't work. Rather, post
code samples here with questions in the areas you need help.
 Jordan> Furthermore, can LineCollection actually do all the things
 Jordan> that quiver's old color commands demand of it? I don't
 Jordan> see a place to set a colormap for a LineCollection, but as
 Jordan> I said, I don't understand it very well.
You can create a line collection that is color mappable by deriving
from LineCollection and ScalarMappable. It will take a little more
work to fully integrate it into the colormappable framework, eg so
colorbars and interactive changing of colormaps works as expected, but
this may be enough to speed you along
This is a good example of how you can extend and specialize the
existing classes if they don't behave like you want them to.
from matplotlib.colors import normalize
from matplotlib.cm import ScalarMappable, jet
from matplotlib.collections import LineCollection
from pylab import figure, show, nx
class LineCollectionSM(LineCollection, ScalarMappable):
 def __init__(self,
 segments,
 x,
 norm,
 cmap, 
 # and the other args for LineCollection
 ):
 LineCollection.__init__(self, segments)
 ScalarMappable.__init__(self, norm, cmap)
 self.set_array(x)
 
 def draw(self, renderer):
 self._colors = self.to_rgba(self.get_array())
 LineCollection.draw(self, renderer)
def random_segment():
 x1, y1, x2, y2 = nx.mlab.rand(4)
 return (x1, y1), (x2, y2)
segments = [random_segment() for i in range(50)]
x = nx.mlab.rand(50)
col = LineCollectionSM(segments, x, normalize(), jet)
fig = figure()
ax = fig.add_subplot(111, xlim=(0,1), ylim=(0,1), autoscale_on=False)
ax.add_collection(col)
show()

Ok, I have some questions about what the protocol for patch submission 
should be, in terms of 'completeness' of the patch.
I have a patch for the quiver function that is half done... it has 
converted the arrows from patches to linecollections, and it will accept 
arbitrary X and Y coordinates for the arrow positions, as suggested by 
Rob. Unfortunetly, none of the color functionality is working. Partly 
this is because the color functionality of LineCollection is different 
from PolyCollection (which quiver originally used) and partly because I 
don't understand how matplotlib sets colors at all. Should I submit 
this half finished patch so that others can have a chance to improve the 
color function? Or should I not submit until I figure out how color 
works and fix the thing?
Furthermore, can LineCollection actually do all the things that quiver's 
old color commands demand of it? I don't see a place to set a colormap 
for a LineCollection, but as I said, I don't understand it very well.
Jordan

> from collections import LineCollection
> class Arrow(LineCollection):
> """
> An arrow
> """
> def __init__( self, x, y, dx, dy, width=1.0, arrowstyle='solid', 
> **kwargs ):
> """Draws an arrow, starting at (x,y), direction and length
> given by (dx,dy) the width of the arrow is scaled by width.
> arrowstyle may be 'solid' or 'barbed'
> """
> L = math.hypot(dx,dy) or 1 # account for div by zero
> S = 0.1
> arrow = {'barbed': array([[0.,0.], [L,0.], [L-S,S/3],
> [L,0.], [L,-S/3], [L,0.]]),
> 'solid': array([[0.,0.], [L-S,0.], [L-S,S/3],
> [L,0.], [L-S,-S/3], [L-S,0.]])
> }[arrowstyle]
>
> cx = float(dx)/L
> sx = float(dy)/L
> M = array([[cx, sx], [-sx, cx]])
> verts = matrixmultiply(arrow, M) + [x,y]
> LineCollection.__init__(self, [tuple(t) for t in verts], 
> **kwargs)
I've found one problem with your Arrow LineCollection; it's not actually 
a line collection. It's one line, so some of the LineCollection 
functions fail on it. You need to break up the arrow into segments, 
like this:
'barbed': array([ [ [0.,0.], [L,0.] ],
 [ [L,0.], [L-S,S/3] ],
 [ [L,0.], [L-S,-S/3] ] ]
Except just doing this will break the matrixmultiply. Just a heads-up.
Jordan

This patch fixed osx's numpy issue and doesn't cause problems on win32
or linux for me. I went ahead and committed it. Thanks Andrew.
- Charlie
On 5/24/06, Andrew Straw <str...@as...> wrote:
> Dear Sam,
>
> Could you please try the following patch? I think it will fix the issue,
> but I'm not sure -- I don't have this problem on my linux system. If it
> works, I'll commit it to svn.
>
> (Robert Kern suggested modifying the setup.py to include a compiler
> command-line directive. IMO this is better because it will be in the
> source file and is thus more visible to anyone who wants to re-use the
> code. Additionally, it will modify the file, triggering a re-build.)
>
> Samuel M. Smith wrote:
>
> >Well, I gave up. I regressed and installed numpy 0.9.6 from the
> >package installer and looks like matplotlib works now.
> >It sure blows my confidence when two months go by and there are
> >enough changes that I can't install from source anymore.
> >I would like to try again but it would be nice to know what you did
> >to get it to work since what I did last time no longer works.
> >
> >Sam
> >
> >_______________________________________________
> >Pythonmac-SIG maillist - Pyt...@py...
> >http://mail.python.org/mailman/listinfo/pythonmac-sig
> >
> >
>
>
>
>

I've been working on quiver a little over the weekend. I refactored it 
so it works with non-regularly spaced X and Y data, and made it use 
Gary's LineArrow code. I don't have the variable colors for the arrows 
working yet though. I'm going to try to get that working before I 
submit my patch. I haven't even tried to do any of the absolute vs data 
coordinate stuff yet.
Jordan

Just a quick progress report.
First, an observation I should make is that despite there being quite a 
lot of documentation in the mpl code, I found it tough going to 
understand what the documentation means. I kept running into jargon and 
assumptions which made it hard to follow. I know it's hard to document 
things, but I think some diagrams and a glossary would be really helpful.
I did in fact spend a few hours trying to understand transforms and 
hacking at the quiver plot code over the weekend and have made no real 
progress. I haven't given up, but given the small amount of time I can 
spend on this, if anyone is hanging out (Jordan?) for improved quiver 
plots, they may want to move ahead independently on it.
Gary
Gary Ruben wrote:
> Thanks John,
> I hope to have another go at this over the weekend but this sounds like 
> a promising avenue,
> Gary R.

Darren,
One more thing: please go ahead and commit your svg patch.
Thanks.
Eric
> Here's a hack that works for me:
> 
> $ svn diff
> Index: lib/matplotlib/backends/backend_svg.py
> ===================================================================
> --- lib/matplotlib/backends/backend_svg.py (revision 2417)
> +++ lib/matplotlib/backends/backend_svg.py (working copy)
> @@ -71,20 +71,25 @@

Darren,
Thanks. I expect that a slight modification of your patch will fit in 
perfectly with what I have in mind, and it is particularly helpful 
because I know next to zip about svg--and about most of the other 
backend output formats.
I think you misunderstood what I was suggesting; it was not that alpha 
would be zero in the svg output, but rather that the backend would use 
alpha==0 in the line color (or gc.alpha) as a flag to not output the 
stroke command, in the same way as I started using linewidth for this. 
In the same way, alpha==0 in the facecolor would turn off output of the 
fill command. So, even if you start with svg and then go to postscript, 
the result should be correct.
It is all a little kludgy. Some things use rgb, some use rgba; some 
alpha values are ignored completely. The GraphicsContextBase has alpha 
but GraphicsContextPS does not. The gc seems to have *almost* all the 
information that gets passed down to the lowest-level renderer 
functions, but lacks the face color; etc. A more thorough rewrite could 
clean up a lot of things, but as John noted it would require 
simultaneously modifying the entire set of backends. Instead, my 
intention is to make small changes that move towards a greater degree of 
consistency but without breaking anything. This does not preclude a more 
extensive refactoring in the future; if anything, it should facilitate it.
Eric
Darren Dale wrote:
> On Saturday 27 May 2006 09:06, Darren Dale wrote:
> 
>>On Saturday 27 May 2006 04:29, Eric Firing wrote:
>>
>>>Darren noticed that because of the edge-drawing problem, ps and svg
>>>backends were making unusable colorbars for image-type plots, so I put a
>>>quick hack into the ps backend to make it work until the more general
>>>solution is put into place.
>>
>>Thank you for doing that. I need to use the svg backend to make plots for
>>my poster. I was thinking about how to change the svg backend, and setting
>>the alpha to zero may create a problem. For example, I create an svg file
>>with mpl, and import it into inkscape. Then I print the document to my
>>postscript printer, which does not support alpha, and therefore some
>>unexpected lines show up on the printed page. Its a corner case, but I bet
>>a fair number of people will get nailed by it.
> 
> 
> Here's a hack that works for me:
> 
> $ svn diff
> Index: lib/matplotlib/backends/backend_svg.py
> ===================================================================
> --- lib/matplotlib/backends/backend_svg.py (revision 2417)
> +++ lib/matplotlib/backends/backend_svg.py (working copy)
> @@ -71,20 +71,25 @@
> else:
> dashes = 'stroke-dasharray: %s; stroke-dashoffset: %f;' % (
> ' '.join(['%f'%val for val in seq]), offset)
> +
> + linewidth = gc.get_linewidth()
> + if linewidth:
> + return 'style="fill: %s; stroke: %s; stroke-width: %f; ' \
> + 'stroke-linejoin: %s; stroke-linecap: %s; %s opacity: %f; ' \
> + '%s"' % (fill,
> + rgb2hex(gc.get_rgb()),
> + linewidth,
> + gc.get_joinstyle(),
> + _capstyle_d[gc.get_capstyle()],
> + dashes,
> + gc.get_alpha(),
> + clippath,)
> + else:
> + return 'style="fill: %s; opacity: %f; ' \
> + '%s"' % (fill,
> + gc.get_alpha(),
> + clippath,)
> 
> - return 'style="fill: %s; stroke: %s; stroke-width: %f; ' \
> - 'stroke-linejoin: %s; stroke-linecap: %s; %s opacity: %f; ' \
> - '%s"' % (
> - fill,
> - rgb2hex(gc.get_rgb()),
> - gc.get_linewidth(),
> - gc.get_joinstyle(),
> - _capstyle_d[gc.get_capstyle()],
> - dashes,
> - gc.get_alpha(),
> - clippath,
> - )
> -
> def _get_gc_clip_svg(self, gc):
> cliprect = gc.get_clip_rectangle()
> if cliprect is None:
> @@ -144,10 +149,10 @@
> y = self.height-y-h
> im.write_png(filename)
> 
> - imfile = file (filename, 'r')
> - image64 = base64.b64encode (imfile.read())
> - imfile.close()
> - os.remove(filename)
> + imfile = file (filename, 'r')
> + image64 = base64.b64encode (imfile.read())
> + imfile.close()
> + os.remove(filename)
> lines = [image64[i:i+76] for i in range(0, len(image64), 76)]
> 
> self._svgwriter.write (
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Jochen" == Jochen Voss <li...@se...> writes:
 Jochen> I think this would be a good idea. Having lines of width
 Jochen> 0 be invisible would satisfy the principle of least
 Jochen> surprise. (If people really would need the current
 Jochen> PostScript backend behaviour, maybe this could be exposed
 Jochen> through a different API?)
Despite my earlier concerns, after thinking about it a bit, my
preference at this point is to not support the postscript behavior. I
think the front-end API should strive for consistency across backends,
rather than supporting backend dependent behavior. So let's go with
linewidth=0 is invisible, unless someone feels strongly otherwise.
JDH