Repository navigation
ylabel clipped with Qt5Agg backend when saving figure to png with both bbox_inches='tight' and pad_inches=0 #8473
Description
Bug report
Using the Qt5Agg backend, applying both bbox_inches='tight' and pad_inches=0 together clips ylabel texts when saving to png format. The same text is not clipped when saving as pdf or with the GTK3Cairo backend.
Code for reproduction
import matplotlib
matplotlib.use('Qt5Agg') ## Causes clipping
#matplotlib.use('GTK3Cairo') ## No clipping
import matplotlib.pyplot as plt
plt.ioff()
plt.plot([1,2,3],[3,1,2])
plt.xlabel('This text is ok. yyggjjpp [] () {}')
plt.ylabel('Top is cut off, for example the fs and brackets. [] () {}')
### Neither PNG nor PDF is clipped with either backend
plt.savefig('test-tight.png',bbox_inches='tight')
plt.savefig('test-tight.pdf',bbox_inches='tight')
### PNG is clipped with Qt5Agg, not GTK3Cairo, pdf is never clipped
plt.savefig('test-tight-nopad.png',bbox_inches='tight',pad_inches=0)
plt.savefig('test-tight-nopad.pdf',bbox_inches='tight',pad_inches=0)Actual outcome
When using backend 'Qt5Agg' in the png output, tall characters in the ylabel are clipped.
Expected outcome
I expect to produce comparable output to the 'GTK3Cairo' backend, which does not clip the labels.
Matplotlib version
All installed from Arch Linux x64 repositories.
- Python 3.6.0
- Matplotlib 2.0.0
- python-pyqt5 5.8
- python-cairocffi 0.8.0
- python-gobject 3.22.0
Activity
WeatherGod commented on Apr 13, 2017
WeatherGod commented on Apr 13, 2017
tacaswell commented on Apr 14, 2017
Someone should track down if agg or cairo is generating the png in the gtk cairo case. If the later, they maybe silently padding?
WeatherGod commented on Apr 14, 2017
github-actions commented on Apr 11, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
oscargus commented on Apr 11, 2023
Still an issue (and the OK text at the bottom is also clipped...):
tacaswell commented on Apr 11, 2023
Possible related to #8265
The check that should be done is if the x and y label padding is slightly adjusted if we find about half the values look OK and and half do not.
jklymak commented on Apr 11, 2023
This looks to be an off-by-one pixel error on the left side (other edges seem ok?) as can be seen by changing the dpi. rounding versus truncating the canvas size seems reasonable, though its strange that the truncating would happen on the left edge (I'd expect the far edge?). I also wonder if rather than truncating we should just always round up.
tacaswell commented on Apr 11, 2023
that is a good point, I think the agg rounding is a red herring.
This instead suggests that there is something funny going on with how we set the transform in the tight bbox logic that it is one pixel too narrow and there is a ceil being used someplace that moves the origin up and to the right.