matplotlib-devel Mailing List for matplotlib (Page 470)

>     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

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 (

Hi Eric,

On Thu, May 25, 2006 at 08:07:14AM -1000, Eric Firing wrote:
> I propose that the backends be changed so that for any patch-like object=
=20
> or collection, setting the boundary linewidth to zero suppresses=20
> rendering of the line.

I think this would be a good idea.  Having lines of width 0 be
invisible would satisfy the principle of least surprise.
(If people really would need the current PostScript backend behaviour,
maybe this could be exposed through a different API?)

All the best,
Jochen
--=20
http://seehuhn.de/

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.

Darren

John,

I have been poking around in the backends and above, and it looks to me 
like _backend_agg.cpp already implements the solution I was moving 
towards (at least in draw_poly_collection), at the backend level: let 
alpha==0 suppress rendering.  This behavior can be added to the backends 
one at a time without breaking anything.  (The backends that don't 
presently support alpha at all, like ps, will need a little more work 
than the ones that do, but I think it is still pretty simple.) Then at 
the higher levels it is just a matter of letting "facecolor='No'" set 
the alphas of the rgba array to zero, etc.  I am inclined to let 
linewidth=0 do the same thing as edgecolor='No', simply because it is 
easy and to me a very intuitive way of saying "Don't draw the boundary"; 
but this is a minor detail.

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.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
>     Eric> I see only advantages and no disadvantages whatsoever to
>     Eric> this change; am I missing something?
> 
> The only potential problem with this is that a linewidth=0 is
> postscript actually means something -- it tells the rendering device
> to draw the thinnest possible line.  The change you propose could
> potentially break some code where people are relying on this.  This
> would not be the end of the world as long as we announce it.
> 
> Alternatively, we could support 'None' for the facecolor and edgecolor.  This
> is a little difficult, unfortunately, since None is overloaded to
> mean "do the default".  The hack workaround we use here is to set
> 'None' (the string) rather than None itself.  Ugly, yes.  
> 
> The real root of the problem is that
> 
>         renderer.draw_polygon(gc, rgbFace, tverts)
> 
> is overloaded to support edge and face drawing in one function call.
> This is a hold-over from the bad-old-days where pcolor and friends use
> polygons for every face, and I wanted to save the function call by
> putting both edge and face drawing in one call.
> 
> One might rather have at the Artist level
> 
>     if facecolor!='None': 
>         gc.set_foreground(facecolor)
>         renderer.draw_polygon(gc, tverts, fill=False)
> 
>     if edgecolor!='None'
>         gc.set_foreground(edgecolor)
>         renderer.draw_polygon(gc, tverts, fill=False)
> 
> or have booleans in the patch object if this is too ugly.
> 
> This is cleaner in my view than using linewidth=0 but I don't feel
> strongly.  However, it would require changing *every* backend.  Argg
> 
> JDH

On 5/26/06, Eric Firing <ef...@ha...> wrote:

> OK, I agree now; let's move away from 'None' as a string.  It can be
> done gradually.  The brevity of 'No' is appealing, and it also works as
> the first two letters of 'None' (so it is extra-easy to support both),
> but the grammar of "color=3D'No'" is poor.  'Invisible' is still a bit
> long.  'Absent' could work.  So could 'Blank', although for French and
> Spanish speakers it is perilously close to their word for white.  Maybe
> 'No' really is the best compromise.

I've used this instead in the past:

class NotGiven: pass

def foo(x,y=3DNotGiven):
  if y is NotGiven:
    y =3D smart_default
  elif y is None:
    y =3D do_the_rigth_thing_for_None
  ...


This lets None be a valid value without the joyfully robust choice of
None and 'None' having drastically different meanings.

Just an idea..

f

On Friday 26 May 2006 14:01, Eric Firing wrote:
> Christopher Barker wrote:
> > Eric Firing wrote:
> >> John Hunter wrote:
> >>> How is it really prone to error -- I would think that if the user pass
> >>> es 'None', the string, for a color arg, there aren't too many
> >>> alternative meanings.
> >>
> >> Right.  'None' means no color--don't draw it.  'Transparent' is
> >> longer, and conceptually closer to alpha=0.  The only potential error
> >> is typing 'None' instead of None, or the reverse.  It could be
> >> confusing to a new user.
> >
> > Or an old user. If I see 'None" in the docs, I'm going to type None. It
> > seems like a really bad idea to have both 'None' and None be valid, but
> > have different meanings.
> >
> > If you don't like 'Transparent', how about 'NoLine', "Invisible", 'No',
> > etc, etc...... but please don't use 'None'
>
> OK, I agree now; let's move away from 'None' as a string.  It can be
> done gradually.  The brevity of 'No' is appealing, and it also works as
> the first two letters of 'None' (so it is extra-easy to support both),
> but the grammar of "color='No'" is poor.  

Its not too bad, if in this case you recognize color as a verb instead of a 
noun...

> 'Invisible' is still a bit 
> long.  'Absent' could work.  So could 'Blank', although for French and
> Spanish speakers it is perilously close to their word for white.  Maybe
> 'No' really is the best compromise.
>
> Eric
>
>
> -------------------------------------------------------
> 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

Christopher Barker wrote:
> Eric Firing wrote:
> 
>> John Hunter wrote:
> 
> 
>>> How is it really prone to error -- I would think that if the user pass
>>> es 'None', the string, for a color arg, there aren't too many
>>> alternative meanings.
>>
>>
>> Right.  'None' means no color--don't draw it.  'Transparent' is 
>> longer, and conceptually closer to alpha=0.  The only potential error 
>> is typing 'None' instead of None, or the reverse.  It could be 
>> confusing to a new user.
> 
> 
> Or an old user. If I see 'None" in the docs, I'm going to type None. It 
> seems like a really bad idea to have both 'None' and None be valid, but 
> have different meanings.
> 
> If you don't like 'Transparent', how about 'NoLine', "Invisible", 'No', 
> etc, etc...... but please don't use 'None'

OK, I agree now; let's move away from 'None' as a string.  It can be 
done gradually.  The brevity of 'No' is appealing, and it also works as 
the first two letters of 'None' (so it is extra-easy to support both), 
but the grammar of "color='No'" is poor.  'Invisible' is still a bit 
long.  'Absent' could work.  So could 'Blank', although for French and 
Spanish speakers it is perilously close to their word for white.  Maybe 
'No' really is the best compromise.

Eric

Eric Firing wrote:
> John Hunter wrote:

>> How is it really prone to error -- I would think that if the user pass
>> es 'None', the string, for a color arg, there aren't too many
>> alternative meanings.
> 
> Right.  'None' means no color--don't draw it.  'Transparent' is longer, 
> and conceptually closer to alpha=0.  The only potential error is typing 
> 'None' instead of None, or the reverse.  It could be confusing to a new 
> user.

Or an old user. If I see 'None" in the docs, I'm going to type None. It 
seems like a really bad idea to have both 'None' and None be valid, but 
have different meanings.

If you don't like 'Transparent', how about 'NoLine', "Invisible", 'No', 
etc, etc...... but please don't use 'None'

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...