Re: [Matplotlib-users] vertical padding in legend
Done, except that it just raises a warning, and still works with the old kwarg. The new kwarg is borderpad; it is used if pad==0, which is the new rc default. I set the default borderpad=0.5. There is still too much other positioning in legend that is based on axes units. I briefly tried to start changing others, again with additional kwargs, and things quickly fell apart. Legend needs considerable reworking to take full advantage of the transforms framework (and maybe other mpl improvements since the original legend) and to put all positioning kwargs and code in sensible units. It is amazing that the present code works as well as it does. The way to make a transition may be via a separate version for a while. There could be a single interface, with a kwarg to choose the version. Thanks Eric. I would like to help reworking on the legend class. I once tried to incorporate the FancyBox into the legend but the result is not satisfactory because the legend bounding box is defined as axes units in the current implementation (see the attached screenshot). And I guess it would be better do things in the display coordinate. Also, in the current implementation, the vertical spacing between each legend varies according to the height of the legend text. For example, in the attached screenshot, the spacings between ac, ag, lg are all different and this is because their text heights are different. I think it is better if we have a fixed spacing, or have a minimum spacing as the text height of lg. And use the baseline-alignment if possible. Regards, -JJ attachment: t.png- 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
Re: [Matplotlib-users] vertical padding in legend
John Hunter wrote: On Tue, Sep 30, 2008 at 5:07 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote: 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. How about using a new kwarg and raising an exception if the old one is passed in, with the exception pointing to the new arg? I am a little uncomfortable silently changing the meaning of the old arg. Done, except that it just raises a warning, and still works with the old kwarg. The new kwarg is borderpad; it is used if pad==0, which is the new rc default. I set the default borderpad=0.5. There is still too much other positioning in legend that is based on axes units. I briefly tried to start changing others, again with additional kwargs, and things quickly fell apart. Legend needs considerable reworking to take full advantage of the transforms framework (and maybe other mpl improvements since the original legend) and to put all positioning kwargs and code in sensible units. It is amazing that the present code works as well as it does. The way to make a transition may be via a separate version for a while. There could be a single interface, with a kwarg to choose the version. 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
Re: [Matplotlib-users] vertical padding in legend
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
