When using the inline pylab backend, the default figure size is set to 6x4. This is too small if the fonts are left as 12pt, and x-labels get cut off if you use a log-scale. This commit tweaks the default font size and bottom padding, so that labels fit.
Even though it's a tiny commit, I make this as a pull request rather than doing it directly on master because I imagine there may be some objection to overriding 3 matplotlib defaults instead of just one, and some may consider the font too small (If anything, I would like it still smaller).
There are also a thousand different ways to make this work, but I don't want to get into a debate of ideal styling, I just wanted to fix a basic error.
Regular scaling of matplotlib 8x6, 12pt defaults by 75% would have:
So our figures have a wider aspect ratio being 6x4, and now even slightly wider since I increased the bottom padding a bit.
Here's an after/before image of the two styles:
tweak default font size for inline pylab backend
xlabels on 6x4 log plots with 12pt font get cut off,
so use 10pt, and increase bottom pad by 25%
Mmh, I don't get the problem:
This is with an empty personal ~/.matplotlib dir, to ensure it's not something about my config that was masking the issue.
Before we make the changes, let's figure out if there's something os- or version-specific causing the problem on your box and not on mine. We may want to narrow their focus, or simply expose a config section for how we configure matplotlib in inline mode...
There's enough space for the non-log labels, but if you have a log-scale, then the tic labels are taller, so the x-label gets pushed off.
This is true of 6x4 log-plots with 12pt font in matplotlib in general, regardless of backend, but the inline backend sets the figsize to 6x4 without making other adjustments, which causes the problem. I can reproduce it on Ubuntu and OSX with IPython 0.10.1 and 0.11, and matplotlib HEAD as well as 0.99.3, with various wx,qt,pdf,inline backends, etc.
I also have no .matplotlib config.
Aha, correct. Sorry, I failed to notice the point about the x axis log scale...
In that case yes, there is a problem. The question is then: do we fix it like this with hardcoded values, or do we introduce a little section of matplotlib configuration that we always execute (with the fixed defaults), but that users could also easily set as a configurable?
I think an inline_rcparams configurable makes perfect sense if there's going to be more than 1 value set. What object should it be attached to?
I think it should be something kernel-side, so that the same formatting parameters go to all frontends. I guess we could for now put it in the global section...
We're really going to have to sit down with a very big sheet of paper and organize our config design. The architecture is solid, but we have pieces here, there and everywhere...
use config.Global.inline_rc to initialize matplotlib with the inline …
Note that this will not be useful until the zmq kernel actually loads configuration from somewhere.
Yes, we do need to work out where everything goes. The system is there, but some consolidation of what settings belong where does need to happen. Fortunately, the framework should make implementing any decision we make fairly straightforward.
I set an inline_rc to be requested from shell.config.Global, with defaults as I had them set (6x4,10pt,.125). inline_rc is just a dict that gets passed to rcParams.update
Note that this will not actually be practically configurable until the zmq kernel actually loads configuration from somewhere, but once you can actually set config.Global.inline_rc, it will be used here.
Because it's global, I'd suggest a more descriptive name: matplotlib_inline_rc, for example.
Other that that, merge away! Thanks for the great work.
rename inline_rc to pylab_inline_rc
Merge branch 'inlinefont'
closed by bf6ff92