autofmt_xdate cropping graph wrongly

[turicas]

When I use Figure.autofmt_xdate (it uses rotation by default) the graph is not moved/scaled so it is cropped in the image.
I noticed this problem when I was trying to crop white border in images using bbox_inches='tight' and pad_inches=0 in Figure.savefig.

My system's info:

• uname -a: Linux E04679 2.6.38-13-generic #53-Ubuntu SMP Mon Nov 28 19:33:45 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
• matplotlib version: 0.99.3, installed using pip
• Nothing in matplotlibrc
• Nothing special in verbose options

The code to reproduce the bug is:

#!/usr/bin/env python
# coding: utf-8

from matplotlib.pyplot import figure
from datetime import datetime


fig = figure()
print fig, type(fig)
subplot = fig.add_subplot(1, 1, 1)
subplot.plot([datetime(2011, 12, 29, 0, 0, 0), datetime(2011, 12, 30, 0, 0, 0),
              datetime(2011, 12, 31, 0, 0, 0), datetime(2012, 1, 1, 0, 0, 0)],
             [1, 8, 27, 64])
fig.autofmt_xdate()
fig.savefig('bug-crop-1.png')
fig.savefig('bug-crop-2.png', bbox_inches='tight', pad_inches=0)

[leejjoon]

I guess you're saying that "bug-crop-2.png" is wrong because the spine line on the right axis is cropped?

This is a very subtle issue and I think it is not directly related to the use of autofmt_xdate.

Similar artifact can be reproduced with the following code.

ax = axes([0,0,1,1])
ax.tick_params(label1On=False, label2On=False)

savefig('bug-crop-1.png')
savefig('bug-crop-2.png', bbox_inches='tight', pad_inches=0.)

The two outputs are identical, thus one may consider that "bbox_inches='tight', pad_inches=0." options work as expected.
However, the outputs are still looks wrong, and it is primarily due to the snapping of lines.

If you turn off snapping, the output looks somewhat right (but lines get blurry).

for spine in ax.spines.values():
    spine.set_snap(False)

As far as I can see, the main problem is that the snapping of lines are not properly accounted when the bbox of the figure is calculated (for the AGG backend). In other words, get_window_extent method does not care about the snapping. And I don't think it can be easily implemented. Maybe, @mdboom has a better idea, though.

My recommendation is not to use 0 for pad_inches. Instead, use small enough value, e.g., 0.01, although it may leave some extra white spaces.

[efiring]

This sounds like a "won't fix, but there is a perfectly good work-around" situation. Closing.