Re: [Matplotlib-users] Scale legend box border, dashed and dotted lines when the figure size is changed

[Eric F. <ef...@ha...>]

On 07/12/2010 01:11 PM, John Hunter wrote:
> On Mon, Jul 12, 2010 at 5:11 PM, Jeffrey Blackburne<je...@mi...>  wrote:
>> Actually, I have been able to do it like this:
>>
>> mpl.rcParams['patch.linewidth'] = 0.2
>>
>> Hope that helps, and sorry I didn't reply sooner.
>
> Of course this will affect any other patches in your figure (eg
> Rectangles from histogram plots, etc).
>
> I am not opposed to adding some legend.frame rc parameters.  Part of
> the purpose of the rc file is to work like a style sheet, so if you
> are writing a book or an article with a bunch of figures, and you want
> them all the have the same look-and-feel, you can customize the
> defaults externally w/o a bunch of boilerplate in your scripts that
> can be difficult to maintain.  It seems like the legend frame
> properties fit into this category.  In particular, the frame alpha is
> one I almost always set to semi-transparent so you can see data behind
> the legend, which is boilerplate I might be happy to do away with if I
> had an rc param.
>
> I would be amenable to adding:
>
>    legend.frame.facecolor : 'white'
>    legend.frame.edgecolor : 'white'
>    legend.frame.linewidth : 1.0
>    legend.frame.alpha : 1.0
>
> but I'd like to hear from others (Eric?) who are already not happy
> with the size of our rc file.  Although this change would increase the
> line count, it doesn't increase the complexity much if at all in my
> view and is somewhat useful.  It would imply some mild potential
> breakage, because currently the legend face and edge colors use the
> axes colors (which is why it would be nice if we had
> containment/inheritance for our rc params so they could inherit from
> parent) so if someone has tweaked their old axes.facecolor, they would
> need to add legend.frame.facecolor under this change to remain
> compatible.

John,

I have no objections to the change you propose, and your idea of adding 
inheritance sounds good, also.  Even nicer might be some flexibility in 
specifying units, so that a pad could scale with fontsize instead of 
being given in points, for example.

My reservations about the rc file approach come partly from the concern 
that it can be too hidden, especially when the filename is prefixed with 
a dot--which, fortunately, we don't do.  Still, a user might 
understandably wonder where the active configuration file really is,
(hint to other readers: try the matplotlib function, matplotlib_fname()) 
and having a program behave differently depending on the current working 
directory when it is run is a double-edged sword.

Style-file functionality is clearly a good thing, so the question is 
whether to make it explicit.  One way to make it more explicit would be 
to invoke it via a script's command line, just as the backend can be 
specified via the command line.  I don't know if it is worth adding this 
as an option, but it might facilitate testing, if nothing else. 
Potentially, the style-file parts of a matplotlibrc file could also be 
read in by a function at any point in a script.

I was also unhappy with situations where the rc mechanism--which really 
should be used for global configuration--was the only mechanism 
available for local customization.  I don't know whether there are still 
such cases, but the one that particularly bothered me--tick 
customization--can now be done without setting and resetting rc parameters.

Enough idle rumination...

Eric

>
> JDH
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users