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/matplotlib-users@lists.sourceforge.net/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
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
···
On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <lee.j.joon@...149...> 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.
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 <jdh2358@...149...> wrote:
On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <lee.j.joon@...149...> 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 <jdh2358@...149...> wrote:
On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <lee.j.joon@...149...> 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options