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
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...
On 07/12/2010 01:11 PM, John Hunter wrote:
On Mon, Jul 12, 2010 at 5:11 PM, Jeffrey Blackburne<jeffb@...1166...> wrote:
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