Scale legend box border, dashed and dotted lines when the figure size is changed

Community matplotlib-users
1

Janne Blomqvist <blomqvist.janne@...287...> writes:

The problem I'm having is that as the figure is then pretty small, I
can scale font sizes, axis sizes, line widths etc., but what I've been
unable to figure out is how to scale dashed or dotted lines, as well
as the thickness of the legend border box.

It seems that there are no rc settings for these, but you can adjust
them as follows:

a.plot(x, y, '--', label='foo bar')

Change this to

  a.plot(x, y, '--', label='foo bar', dashes=(2,2))

The value of dashes is the number of points of ink followed by the
number of points of whitespace. It defaults to (6,6) for the '--'
linestyle (found in the dashd dictionary of backend_bases.py).

a.legend()

Change this to

  lg = a.legend()
  fr = lg.get_frame()
  fr.set_lw(0.2)

···

--
Jouni K. Seppänen

2

Thanks, this solved it. A bit annoying that it can't be done with rc
params, but hey, at least it works.

···

On Sat, Jul 10, 2010 at 18:42, Jouni K. Seppänen <jks@...397...> wrote:

Janne Blomqvist <blomqvist.janne@...287...> writes:

The problem I'm having is that as the figure is then pretty small, I
can scale font sizes, axis sizes, line widths etc., but what I've been
unable to figure out is how to scale dashed or dotted lines, as well
as the thickness of the legend border box.

It seems that there are no rc settings for these, but you can adjust
them as follows:

a.plot(x, y, '--', label='foo bar')

Change this to

a.plot(x, y, '--', label='foo bar', dashes=(2,2))

The value of dashes is the number of points of ink followed by the
number of points of whitespace. It defaults to (6,6) for the '--'
linestyle (found in the dashd dictionary of backend_bases.py).

a.legend()

Change this to

lg = a.legend()
fr = lg.get_frame()
fr.set_lw(0.2)

--
Janne Blomqvist

3

Hi Janne,

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.

-Jeff

···

On Jul 12, 2010, at 5:45 PM, Janne Blomqvist wrote:

a.legend()

Change this to

lg = a.legend()
fr = lg.get_frame()
fr.set_lw(0.2)

Thanks, this solved it. A bit annoying that it can't be done with rc
params, but hey, at least it works.

4

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.

JDH

···

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

5

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

···

On 07/12/2010 01:11 PM, John Hunter wrote:

On Mon, Jul 12, 2010 at 5:11 PM, Jeffrey Blackburne<jeffb@...1166...> wrote:

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
matplotlib-users List Signup and Options