Re: [Matplotlib-users] vertical padding in legend
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 - 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
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 <>- 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
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=100&url=/ ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] vertical padding in legend
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. JDH - 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
Re: [Matplotlib-users] vertical padding in legend
Hi Jae-Joon, JL> I just had a quick look at this problem. And I'm posting a quick JL> 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 - 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
Re: [Matplotlib-users] vertical padding in legend
Christopher Brown wrote: > Hi List, > > Attached is a closeup of two legends on a 2-panel figure. The first > legend has 10 plots listed, the second has 1. I have set each legend > identically: loc='upper right', pad=.3, handlelen=.1, handletextsep=.05. > But it seems that while the horizontal padding is the same, the vertical > padding is too large in the first legend, and too small in the second. > The only difference between the two I am aware of is the number of plots > listed (not contained in the axes, but listed in the legends). I'm using > version 0.98.3 on windows. Any ideas? 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. 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
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=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
Re: [Matplotlib-users] vertical padding in legend
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
