vertical padding in legend

Christopher Brown wrote:

Sorry, meant to send to the list...

Hi Eric,

> > the vertical padding is too large in the first
> > legend, and too small in the second.
>
> This looks to me like a design flaw: the pad is "fractional"
> (fraction of legend box size), when logically it should be in
> something like units of legend text height, or possibly in points.
> This might be easy enough to change, although for backwards
> 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

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 <efiring@...202...> wrote:

Christopher Brown wrote:

Sorry, meant to send to the list...

Hi Eric,

> > the vertical padding is too large in the first
> > legend, and too small in the second.
>
> This looks to me like a design flaw: the pad is "fractional"
> (fraction of legend box size), when logically it should be in
> something like units of legend text height, or possibly in points.
> This might be easy enough to change, although for backwards
> 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

Hi Jae-Joon,

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

My figure looks great with these changes. Thank you very much!

···

--
Christopher Brown, Ph.D.
Department of Speech and Hearing Science
Arizona State University

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.

JDH

···

On Tue, Sep 30, 2008 at 5:07 PM, Jae-Joon Lee <lee.j.joon@...287...> 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.

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

···

On Tue, Sep 30, 2008 at 5:07 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:

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

t.png

Jae-Joon Lee wrote:

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.

Jae-Joon,

It would be great if you would take this on. I agree about the spacing. I suspect there are good opportunities for factoring out parts of the problem in such a way that they can be used more flexibly in legend, and may turn out to be useful elsewhere. An ability to nicely format plot elements (line segments, etc.) with text into a block would facilitate satisfying another request that has come up: a legend with more than one column, or a legend that is entirely horizontal.

Eric