On 07/12/2010 01:11 PM, John Hunter wrote: > On Mon, Jul 12, 2010 at 5:11 PM, Jeffrey Blackburne<je...@mit.edu> 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 > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users ------------------------------------------------------------------------------ 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
