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=100&url=/
> _______________________________________________
> 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=100&url=/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
