Re: [Matplotlib-users] vertical padding in legend

2008-09-30 Thread Jae-Joon Lee
Hello,

I just had a quick look at this problem. And I'm posting a quick
solution in case Christoper haven't dig it yet.


Index: lib/matplotlib/legend.py
===
--- lib/matplotlib/legend.py(revision 6138)
+++ lib/matplotlib/legend.py(working copy)
@@ -532,7 +532,11 @@
 # Set the data for the legend patch
 bbox = self._get_handle_text_bbox(renderer)

-bbox = bbox.expanded(1 + self.pad, 1 + self.pad)
+#bbox = bbox.expanded(1 + self.pad, 1 + self.pad)
+bbox = bbox.transformed(self.get_transform())
+bbox = bbox.padded(self.pad*self.fontsize)
+bbox = bbox.inverse_transformed(self.get_transform())
+
 l, b, w, h = bbox.bounds
 self.legendPatch.set_bounds(l, b, w, h)



The problem is already well explained by Eric. And my solution is to
interpret the legend.pad as a fraction of the textsize (pad=0.3 seems
to work fine in my eyes). Note that this breaks the backward
compatibility. I personally think the original behavior may have
produced unsatisfactory results in most of the cases and keeping it as
a default may not be a good idea. While I hope others come out with an
elegant solution, I prefer to break the API in this case.

Regards,

-JJ



On Tue, Sep 30, 2008 at 3:38 PM, Eric Firing [EMAIL PROTECTED] wrote:
 Christopher Brown wrote:
 Sorry, meant to send to the list...

 Hi Eric,

 EF  the vertical padding is too large in the first
 EF  legend, and too small in the second.
 EF
 EF This looks to me like a design flaw: the pad is fractional
 EF (fraction  of legend box size), when logically it should be in
 EF something like units  of legend text height, or possibly in points.
 EF This might be easy enough  to change, although for backwards
 EF compatibility we would need to use a  new kwarg.

 Could you point me to the function where this change needs to occur? I'd
 like to hack at it, because I have deadline for a figure. I'm searching
 around in legend.py, is that where I should be looking?

 Yes, that is the place.  In principle it should be easy to fix, and
 maybe it is...or maybe it isn't.  It will certainly have to do with
 transforms, and using the right one the right way in the right place.


 Also, why would a new kwarg be necessary? If the change simply means
 that the vertical padding is computed correctly, how would that break
 backward compatibility?


 Because the workaround is to fiddle with the pad value for each
 individual case to make the plot look right, so scripts with that
 workaround would fail if suddenly the pad kwarg were to be interpreted
 in sane units.

 The new kwarg could be pad_units, as a modifier for the pad kwarg.  Or
 something like a padpoints kwarg could be introduced as an overlapping
 replacement. Or we could just break the API and hope it doesn't cause
 too much trouble.  I am not sure what the right approach is in this
 case.  I'm also not sure whether this is the only place where a pad
 value is still in poorly-chosen units. There was another such case that
 we fixed quite a long time ago.

 Eric


 -
 This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
 Build the coolest Linux based applications with Moblin SDK  win great prizes
 Grand prize is a trip for two to an Open Source event anywhere in the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 Matplotlib-users mailing list
 Matplotlib-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


[Matplotlib-users] axes3D

2008-09-30 Thread Lisa Tauxe
Are there any plans for incorporating this (what used to be mplot3d)  
into the new matplotlib version?




Lisa Tauxe
Scripps Institution of Oceanography
La Jolla, CA 92093-0220
tel: (858) 534-6084
fax: (858) 534-0784
http://magician.ucsd.edu/~ltauxe/
[EMAIL PROTECTED]

NOTE: Fedex or other courier deliveries address:

300C Ritter Hall
8635 Discovery Way
La Jolla, CA 92037





-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users