matplotlib-devel Mailing List for matplotlib (Page 2)

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

John Hunter wrote:
>>>>>>"Christopher" == Christopher Barker <Chr...@no...> writes:
> 
> 
>     Christopher> John Hunter wrote:
>     >> mean "do the default".  The hack workaround we use here is to
>     >> set 'None' (the string) rather than None itself.  Ugly, yes.
> 
>     Christopher> and really, really prone to error. If you need to use
>     Christopher> a string, use something else, like perhaps
>     Christopher> "transparent"
> 
> 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.

> 
>     >> 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.
> 
>     Christopher> That's actually a good thing. I like to think of a
>     Christopher> polygon with a border a single object, and it can
>     Christopher> dome in handy if you want to do something like draw a
>     Christopher> polygon with a border that is
>     Christopher> semi-transparent. drawing the fill and the stroke
>     Christopher> independently doesn't work right.
[....]
> 
> You may be right -- it may be a good thing -- what we need is a clear
> way to say "edge on" or "face on".  One way is to figure out a way to
> do it with the color specification itself ('None' or something like
> it).  Another way is to add boolean flags to the gc object...

But the gc object is at a lower level, not exposed to the user, so 
something like "color='None'" or "linewidth=0" is needed in any case at 
the higher levels, isn't it?  Or were you thinking of adding another 
kwarg to the high-level functions, that would be passed down the line 
into the backend?  Something like draw=face|edge|both?

Now I see the problem with linewidth=0; it solves only half the problem, 
turning off the boundary rendering, but does not facilitate the reverse, 
leaving the interior unfilled but drawing the boundary.

Eric

>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:

    Christopher> John Hunter wrote:
    >> mean "do the default".  The hack workaround we use here is to
    >> set 'None' (the string) rather than None itself.  Ugly, yes.

    Christopher> and really, really prone to error. If you need to use
    Christopher> a string, use something else, like perhaps
    Christopher> "transparent"

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.

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

    Christopher> That's actually a good thing. I like to think of a
    Christopher> polygon with a border a single object, and it can
    Christopher> dome in handy if you want to do something like draw a
    Christopher> polygon with a border that is
    Christopher> semi-transparent. drawing the fill and the stroke
    Christopher> independently doesn't work right. I was recently
    Christopher> messing around with this in Cairo, and it's a pain
    Christopher> int eh *&^, but it can be done right, but it's up to
    Christopher> the back-end to figure out how.

You may be right -- it may be a good thing -- what we need is a clear
way to say "edge on" or "face on".  One way is to figure out a way to
do it with the color specification itself ('None' or something like
it).  Another way is to add boolean flags to the gc object...

JDH

John Hunter wrote:
> mean "do the default".  The hack workaround we use here is to set
> 'None' (the string) rather than None itself.  Ugly, yes.  

and really, really prone to error. If you need to use a string, use 
something else, like perhaps "transparent"


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

That's actually a good thing. I like to think of a polygon with a border 
a single object, and it can dome in handy if you want to do something 
like draw a polygon with a border that is semi-transparent. drawing the 
fill and the stroke independently doesn't work right. I was recently 
messing around with this in Cairo, and it's a pain int eh *&^, but it 
can be done right, but it's up to the back-end to figure out how.

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

On Thursday 25 May 2006 14:30, 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.

I would be surprised if anyone is relying on this behavior. I think I remember 
reading in a book on postscript that use of this feature is discouraged.

>>>>> "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 Thursday 25 May 2006 14:07, Eric Firing wrote:
> Darren, John, et al.,
>
> At present it is impossible to render a patch with exactly the
> dimensions specified because a boundary is required.  Present
> workarounds include setting the boundary color to the face color and
> setting a small or zero linewidth.  This is inefficient--a line is being
> rendered when it is not wanted--and imprecise, because the result of a
> very thin or zero-width line depends on the backend and output device.

My understanding is that a zero-width line in postscript will be rendered as a 
line with thickness equal to the resolution of the device. So the behavior 
does vary across backends.

> I propose that the backends be changed so that for any patch-like object
> or collection, setting the boundary linewidth to zero suppresses
> rendering of the line.
>
> I see only advantages and no disadvantages whatsoever to this change; am
> I missing something?

I don't claim to be an authority, but I can't think of any problems this might 
raise. Probably it could be done in the ps backend by simply wrapping the 
stroke commands in a check for zero line width. 

> If the proposal meets approval, I can work on it, although I don't know
> which of the backends I can quickly understand well enough (and test) to
> do this. At least the ps backend looks easy with respect to this change.
> Of course, I would be delighted to see the backend maintainers take this
> on.
>
> Comments?  Alternative proposals?

Darren, John, et al.,

At present it is impossible to render a patch with exactly the 
dimensions specified because a boundary is required.  Present 
workarounds include setting the boundary color to the face color and 
setting a small or zero linewidth.  This is inefficient--a line is being 
rendered when it is not wanted--and imprecise, because the result of a 
very thin or zero-width line depends on the backend and output device.

I propose that the backends be changed so that for any patch-like object 
or collection, setting the boundary linewidth to zero suppresses 
rendering of the line.

I see only advantages and no disadvantages whatsoever to this change; am 
I missing something?

If the proposal meets approval, I can work on it, although I don't know 
which of the backends I can quickly understand well enough (and test) to 
do this. At least the ps backend looks easy with respect to this change. 
Of course, I would be delighted to see the backend maintainers take this on.

Comments?  Alternative proposals?

Eric

Helge,

I have committed some changes to the colorbar positioning code that I 
think fix the bug you found--which was actually a difference between the 
way positioning worked in interactive mode versus in a script--and 
generally improved it.  There is a new kwarg, 'pad', to control the 
spacing.  It is a fraction of the original parent axes.  Defaults are 
0.05 for vertical axes and 0.15 for horizontal; in the latter case, it 
has to leave room for axis tick labels and the x-axis title.  I think 
you will find the defaults tolerable.

The automatic repositioning is crude; it is suitable for interactive 
use, but for production plots people will often need to explicitly size 
and position the primary axes and the colorbar axes.  It can probably be 
improved with a few tweaks here and there, but to do a much better job 
automatically would require major changes, and I don't think this should 
be a high priority. On the other hand, it is possible that redesigning 
positioning and aspect-ratio handling to take full advantage of all the 
wizardry in the transforms code would be a big step forward--but 
probably not an easy one.  I am not going to try it right now.

Thanks again for the clear bug report.

Eric

Helge Avlesen wrote:
> Hi,
> just a small wish for the new colorbar;  I think it by default may be
> positioned a bit too close to the figure,
> see examples below. (plotted by this sequence with yesterdays svn checkout)

Helge,

This is actually a bug in the colorbar positioning that shows up when it 
is put next to a narrow plot.  I will take another look at the 
positioning logic.  Thanks for the report.

Eric

Helge Avlesen wrote:
> Hi,
> just a small wish for the new colorbar;  I think it by default may be
> positioned a bit too close to the figure,
> see examples below. (plotted by this sequence with yesterdays svn checkout)

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I was not aware that my TextWithDash refactor had broken
    Darren> anything. Is this something I should look into?

Basically, mplot3d was using private variables of TextWithDash
(relying on the "has a Text"  rather than "is a Text"
implementation).  So you shouldn't feel bad because your refactor
didn't affect the public API.

You are welcome to look at it, but it's on my list of things to do so
don't feel obligated.

JDH

Looks good, but I think it also needs a 'width' or 'weight' kwarg.
I was also thinking of putting at least a couple of different arrow 
styles in via an 'arrowstyle' kwarg, so I'd pass those through to the 
Arrow LineCollection.

Gary R.

Rob Hetland wrote:
> It might make some sense to rethink the quiver API, especially since it 
> seems there are a few people working toward the same goal (I will help, 
> too, if someone can give me some tasks..).
> 
> Here's a strawman quiver API:
> 
> quiver(x, y, u, v, color='b', scale=1.0, scale_to_grid=False, **kwargs)
> 
>   x, y - quiver should be able to handle *random* (x, y) points (right 
> now, it seems to expect meshed positions -- it seems this is 
> an unnecessary constraint.)
> 
>   color - could be a plot-style color (e.g., 'b', 'k', 'm'), a tuple, or 
> an array the same size as x and y to be mapped using the colormap.
> 
>   scale - is a multiplier for the vector length.
> 
>   scale_to_grid - is a boolean that specifies whether the vectors should 
> be in grid coordinates (True), or scaled to fit nicely (False -- vectors 
> are scaled to fit nice, then multiplied by scale).
> 
>   Plus all the normal kwargs (e.g., cmap). 
> 
> 
> Other potential things to consider include scaling the aspect of the 
> vectors so that the grid can have an aspect ratio unequal to one, but 
> the vectors still scale correctly (i.e., u and v have the same length, 
> even when x is twice y).  
> 
> Finally, I have always wanted an easy way to do curly vectors -- similar 
> to streaklines --  but this might be beyond the scope of the simple 
> quiver command.
> 
> -Rob

I was not aware that my TextWithDash refactor had broken anything. Is this 
something I should look into?

Darren

On Wednesday 24 May 2006 08:58, John Hunter wrote:
> >>>>> "Stefan" == Stefan van der Walt <st...@su...> writes:
>
>     Stefan> But, after fixing all these problems, I still can't get it
>     Stefan> to plot.  It might be worth including surface.py in the
>     Stefan> examples directory, as a test, to guarantee that the 3D
>     Stefan> code gets updated with the rest.
>
>     Stefan> It could be that I am missing something completely obvious
>     Stefan> -- I'd appreciate any help in getting it running!
>
> This code is known to be broken (and never worked).  John Porter's
> code originally worked as an add-on module to matplotlib.  Since then
> TextWithDash has been refactored which broke mplot3d.  I've been
> planning to refactor the code to make it work internally, eg like the
> rest of pylab, but haven't gotten it done yet.
>
> JDH
>
>
> -------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

Thanks John,
I hope to have another go at this over the weekend but this sounds like 
a promising avenue,
Gary R.

On May 23, 2006, at 2:02 PM, Eric Firing wrote:

> I have committed changes in color handling that allow the  
> collection initializers to accept the usual flexible mpl color  
> specifications. Your message about quiver prompted me to try  
> examples/quiver_demo.py, which is not run by backend_drivers.py,  
> and which I had therefore not tested. It doesn't work now--and it  
> doesn't make any sense to me, either. (E.g., what on earth is  
> "color=True" supposed to mean?) That is, it is not clear to me what  
> the quiver invocations in the demo are supposed to do based on the  
> quiver doc string.  The simplest quiver invocation works, but it  
> looks to me like the argument handling beyond that is broken, and I  
> don't think it is entirely the fault of my recent changes.  I can  
> help straighten it out, given a clear specification of what quiver  
> is actually supposed to do with various argument combinations.  Let  
> me know if and when this would be useful.


It might make some sense to rethink the quiver API, especially since  
it seems there are a few people working toward the same goal (I will  
help, too, if someone can give me some tasks..).

Here's a strawman quiver API:

quiver(x, y, u, v, color='b', scale=1.0, scale_to_grid=False, **kwargs)

   x, y - quiver should be able to handle *random* (x, y) points  
(right now, it seems to expect meshed positions -- it seems this is  
an unnecessary constraint.)

   color - could be a plot-style color (e.g., 'b', 'k', 'm'), a  
tuple, or an array the same size as x and y to be mapped using the  
colormap.

   scale - is a multiplier for the vector length.

   scale_to_grid - is a boolean that specifies whether the vectors  
should be in grid coordinates (True), or scaled to fit nicely (False  
-- vectors are scaled to fit nice, then multiplied by scale).

   Plus all the normal kwargs (e.g., cmap).


Other potential things to consider include scaling the aspect of the  
vectors so that the grid can have an aspect ratio unequal to one, but  
the vectors still scale correctly (i.e., u and v have the same  
length, even when x is twice y).

Finally, I have always wanted an easy way to do curly vectors --  
similar to streaklines --  but this might be beyond the scope of the  
simple quiver command.

-Rob

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

>>>>> "Gary" == Gary Ruben <gr...@bi...> writes:

    Gary> I did a tiny bit of work on this over the weekend too and
    Gary> decided to try to use a LineCollection instead of patches
    Gary> inspired by Chris Barker's code, but removing his polar
    Gary> coordinate stuff. Lines seemed a more promising way to go
    Gary> for the arrows, although the width should scale down when
    Gary> the arrows get small so that they're never wider than their
    Gary> length. Using a line collection may not permit this. I also
    Gary> haven't got it working yet. FWIW, Jordan's explanations of
    Gary> expected behaviour have been spot on so far. Also, I'd be
    Gary> happy to see the API fixed up a bit.

You can derive a custom line collection which has this behavior --
LineCollection supports an independent linewidth for each segment, so
as long as you keep an array of linewidths and an array of arrow
lengths, you can clip or set the linelengths at draw time or at
segment setting time.  draw time is probably more appropriate, since
then you can account for figure window size under resizes, etc....

JDH

Hi,
just a small wish for the new colorbar;  I think it by default may be
positioned a bit too close to the figure,
see examples below. (plotted by this sequence with yesterdays svn checkout)

... load data
axis('image')
axis([0,IM,0,JM])
C =3D contourf(x,y,H,levels)
colorbar(C)
hsv()
xlabel('X')
ylabel('Y')
grid(linestyle=3D':')

part of the reason is that I normally use long, outward pointing ticks,
so an extra argument to colorbar to in some way adjust the position
relative to the figure would be useful. Otherwise the new colorbar
works very well!

thanks,
Helge

I did a tiny bit of work on this over the weekend too and decided to try 
to use a LineCollection instead of patches inspired by Chris Barker's 
code, but removing his polar coordinate stuff. Lines seemed a more 
promising way to go for the arrows, although the width should scale down 
when the arrows get small so that they're never wider than their length. 
Using a line collection may not permit this. I also haven't got it 
working yet. FWIW, Jordan's explanations of expected behaviour have been 
spot on so far. Also, I'd be happy to see the API fixed up a bit.

Gary R.

Jordan Dawe wrote:
> 
>> The length of that proposed keyword is a warning flag that it may also 
>> be a bad design.  Again, I would say either eliminate built-in support 
>> for color-by-length, or implement it via "color='length'", and then 
>> intercept that non-standard 'length' specification inside quiver so 
>> that it never gets passed to the standard color-handling routines.
>>
>> Now that you have explained it, I am inclined to either do a quick-fix 
>> of the present quiver so that it works again roughly as-is, or change 
>> the example so that it does not use the undocumented(?) "color=True" 
>> syntax; is one of these alternatives OK with you?   Do you have a 
>> preference?  Or do you already have an improved version that we can 
>> substitute now?  One way or another, I don't want to leave a 
>> non-functioning demo in svn.
> I would remove it; if we want a quiver function with color as length, we 
> could create a wrapper function to do that.  I would lean towards making 
> people generate their own color array based on the array length.  I'm 
> not going to have a new quiver anytime soon I think--a friend of mine 
> today pointed out that matlab distorts quiver arrows just like 
> matplotlib does.  In matlab it isn't as noticable, however, since matlab 
> impliments quiver as lines instead of as polygons.  In the short term, 
> I'm seriously tempted to just make matplotlib do the same.
> 
> Jordan