Hello, I have been putting some initial effort on implementing a new Legend class which has paddings in canvas unit. A related post is http://www.mail-archive.com/mat...@li.../msg08560.html My current implementation has a same functionality as the old one (an example figure attached), but I haven't implemented a new features like multicolumn option yet. Basic idea is to create a new version of the Legend class with a same interface to the current one. Eric's original suggestion was to use some optional kwarg to choose the version. But I found this approach does not work well unless we also set the meaningful default values in the rc file. For example, the current "legend.axespad" in rcsetup.py is 0.02 which is in axes unit. But this need to be ~10 (if given in points) or ~0.5 (if given in fraction of the font size) in the new class. One option I can think of is a work flow something like below. import matplotlib.legend matplotlib.legend.use_newclass(True) # this simply override the rcParam with new default values and bind legend.Legend to the new class. # do some stuff matplotlib.legend.use_newclass(False) # recover the original rcParam and rebind legend.Legend back to the original class So, how do others think? Any idea or suggestion is welcomed. Regards, -JJ
On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Basic idea is to create a new version of the Legend class with a same
> interface to the current one.
> Eric's original suggestion was to use some optional kwarg to choose the version.
> But I found this approach does not work well unless we also set the
> meaningful default values in the rc file. For example, the current
> "legend.axespad" in rcsetup.py is 0.02 which is in axes unit. But this
> need to be ~10 (if given in points) or ~0.5 (if given in fraction of
> the font size) in the new class.
I think we should deprectate the axes pad kwarg. If you see it coming
in (not None), make a reasonable points approximation to a pad using
the figure dimensions and axes dimensions and dpi, and issue a warning
padpoints = # compute something here from figsize, axes rect and axespad
warnings.warn("axespad is a deprecated argument to legend. The
new argument is "padpoints" and is in points. Assuming %1.1f
ponts"%padpoints)
That way we won't go crazy supporting 2 versions of something, users'
code won't break initially or fail silently, nd users will have a
clear migration path.
Does that work? Anyone who is using axespad is something of a power
user and will have no problem fixing up their code.
JDH
John,
The current legend class has following options given in axes units.
pad, labelsep, handlelen, hadletextsep, axespad
Eric introduced borderpad (given as a fraction of the font size),
which replaces "pad".
One way is to introduce new names for all of above options. Eric's
suggestion was (in my understanding) to use same names, but have a
some way to select between the old behavior and the new one.
And my inclination was to go with Eric's suggestion instead of
inventing new names. Anyhow, I'm happy with either approach.
If we're inventing new option names, I guess there would be no problem
I mentioned in the previous mail.
Regards,
-JJ
On Thu, Oct 30, 2008 at 7:15 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> Basic idea is to create a new version of the Legend class with a same
>> interface to the current one.
>> Eric's original suggestion was to use some optional kwarg to choose the version.
>> But I found this approach does not work well unless we also set the
>> meaningful default values in the rc file. For example, the current
>> "legend.axespad" in rcsetup.py is 0.02 which is in axes unit. But this
>> need to be ~10 (if given in points) or ~0.5 (if given in fraction of
>> the font size) in the new class.
>
> I think we should deprectate the axes pad kwarg. If you see it coming
> in (not None), make a reasonable points approximation to a pad using
> the figure dimensions and axes dimensions and dpi, and issue a warning
>
> padpoints = # compute something here from figsize, axes rect and axespad
> warnings.warn("axespad is a deprecated argument to legend. The
> new argument is "padpoints" and is in points. Assuming %1.1f
> ponts"%padpoints)
>
> That way we won't go crazy supporting 2 versions of something, users'
> code won't break initially or fail silently, nd users will have a
> clear migration path.
>
> Does that work? Anyone who is using axespad is something of a power
> user and will have no problem fixing up their code.
>
> JDH
>
Jae-Joon Lee wrote:
> John,
>
> The current legend class has following options given in axes units.
>
> pad, labelsep, handlelen, hadletextsep, axespad
>
> Eric introduced borderpad (given as a fraction of the font size),
> which replaces "pad".
> One way is to introduce new names for all of above options. Eric's
> suggestion was (in my understanding) to use same names, but have a
> some way to select between the old behavior and the new one.
> And my inclination was to go with Eric's suggestion instead of
> inventing new names. Anyhow, I'm happy with either approach.
> If we're inventing new option names, I guess there would be no problem
> I mentioned in the previous mail.
Assuming good, descriptive names can be found--whether recycling the old
ones or choosing new ones--the larger question is what the preferred
units should be for which options. I think it makes sense for axespad
to remain in axes units, but all the others seem most natural to me in
fraction of the font size, not in points. With the former, it is like
specifying "doublespace" in a document; the whole legend, and everything
in it, should have proportions that are scale-independent and font-size
independent. With points, you have to adjust 4 options if you change
your font size. I think that *all* pads involving text placement should
scale with the corresponding font size. This applies to tick label
pads, axis label pads also. That way, if you need to make a figure for
publication or beamer display, with extra-large text, it will look right
when you merely change the font sizes--you won't have to adjust all the
pads at the same time.
Eric
>
> Regards,
>
> -JJ
>
>
> On Thu, Oct 30, 2008 at 7:15 AM, John Hunter <jd...@gm...> wrote:
>> On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <lee...@gm...> wrote:
>>> Basic idea is to create a new version of the Legend class with a same
>>> interface to the current one.
>>> Eric's original suggestion was to use some optional kwarg to choose the version.
>>> But I found this approach does not work well unless we also set the
>>> meaningful default values in the rc file. For example, the current
>>> "legend.axespad" in rcsetup.py is 0.02 which is in axes unit. But this
>>> need to be ~10 (if given in points) or ~0.5 (if given in fraction of
>>> the font size) in the new class.
>> I think we should deprectate the axes pad kwarg. If you see it coming
>> in (not None), make a reasonable points approximation to a pad using
>> the figure dimensions and axes dimensions and dpi, and issue a warning
>>
>> padpoints = # compute something here from figsize, axes rect and axespad
>> warnings.warn("axespad is a deprecated argument to legend. The
>> new argument is "padpoints" and is in points. Assuming %1.1f
>> ponts"%padpoints)
>>
>> That way we won't go crazy supporting 2 versions of something, users'
>> code won't break initially or fail silently, nd users will have a
>> clear migration path.
>>
>> Does that work? Anyone who is using axespad is something of a power
>> user and will have no problem fixing up their code.
>>
>> 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-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel