matplotlib

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

> 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

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?

>>>>> "Eric" == Eric Firing <efiring@...> 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:30, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <efiring@...> 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.

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

Chris.Barker@...

>>>>> "Christopher" == Christopher Barker <Chris.Barker@...> 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:
>>>>>>"Christopher" == Christopher Barker <Chris.Barker@...> 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

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

Chris.Barker@...

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

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
> Matplotlib-devel@...
> 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

dd55@...
office: (607) 255-9894
fax: (607) 255-9001

On 5/26/06, Eric Firing <efiring@...> 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

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

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

>>>>> "Jochen" == Jochen Voss <lists@...> 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

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
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

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)