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 <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <[EMAIL PROTECTED]> 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
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
