Repository navigation
Inconsistent inset_axes position between show(), savefig(format='png') and savefig(format='pdf') #8120
Description
Bug report
Bug summary
inset_axes inconsistently positioned between show(), savefig(...,format='png') and savefig(...format='pdf') when the dpi option is set.
Code for reproduction
import matplotlib.pyplot as plt
from mpl_toolkits.axes_grid1.inset_locator import inset_axes
fig = plt.figure(dpi=150);
ax1 = plt.gca()
ax1ins1 = inset_axes(ax1, width=.7, height=.7,bbox_to_anchor=(100,100))
plt.savefig("test.pdf",format='pdf',dpi=300,bbox_inches="tight")
plt.savefig("test.png",format='png',dpi=300,bbox_inches="tight")
plt.show()Actual outcome
PDF:
PNG:
show():
Expected outcome
I would expect all the results to come out the same.
Matplotlib version
- Matplotlib 2.0.0 (conda)
- Python 2.7.13 (conda)
- Platform: Linux
Activity
[-]Inconsistent inset_axes position between show(), savefig(format='[/-][+]Inconsistent inset_axes position between show(), savefig(format='png') and savefig(format='pdf')[/+]sorenrasmussen commentedon Feb 21, 2017
Note:
Setting
bbox_transform=ax1.figure.transFigurefor theinset_axesmakes the positioning consistent. However, I would still expect it to be consistent without doing so.tacaswell commentedon Feb 21, 2017
Setting the figure dpi to 300 should also work.
There is a dpi dependence in there someplace...
sorenrasmussen commentedon Feb 21, 2017
Setting the figure DPI to 300 makes the PNG look right, but not the PDF.
tacaswell commentedon Sep 24, 2017
attn @jklymak as another case of pdf / dpi issues
jklymak commentedon Sep 24, 2017
Yes. I think it's easy to fix (in general I think the rendered width should just return 72 times the inches width so it's in pdfs dpi units like the other backends. But terrifying to then fix all the workarounds that have been added here and there!
ImportanceOfBeingErnest commentedon Apr 17, 2018
I updated the documentation of
inset_axesin #11060. Among other things it now includes the sentenceThere are also several examples added. The code does not forbid to specify a bounding box in pixels and use the default transform=None (i.e. the display coordinates), as this may still be useful in some limited cases. However I hope that the docs and examples are now clear enough such that people will not try to position something in pixel coordinates and then wonder why there is some dpi dependence introduced.
jklymak commentedon Feb 12, 2019
I think this has substantively been fixed by the doc changes...