FIX: tickspacing for subfigures#20771
Conversation
ebe6d09 to
357cfe5
Compare
|
Again, prob not urgent for 3.4.3... |
|
Should we check for all instances of |
|
Lets move to draft and I'll do a census as @anntzer suggests. As a note, I notice that the new test also makes the markersize change with dpi, which I don't think happens with normal figures. |
|
A quick scan doesn't show any other cases. Note |
|
See #20777 for another case. |
78956c3 to
3e7dc9b
Compare
|
This now includes a setter/getter property for |
3e7dc9b to
8a3ce1d
Compare
| def dpi(self): | ||
| return self._parent.dpi | ||
|
|
||
| @dpi.setter |
There was a problem hiding this comment.
not sure we want the setter here? The getter makes sense as we may need this in the transforms, but do we want to be able to change the dpi of the whole figure from a sub figure?
On the other hard it seems realtively harmless and makes sure that subfigures feel as like figures as they can.
There was a problem hiding this comment.
I actually tried it, and it breaks some tests without the setter. I did not investigate any further though, so I don't know if that's a real problem or not.
There was a problem hiding this comment.
Happy to mess around with that. I'd say dpi is one of our more fragile concepts.
…771-on-v3.4.x Backport PR #20771 on branch v3.4.x (FIX: tickspacing for subfigures)
PR Summary
Closes #20765
tick spacing was incorrect for subfigure. The issue was pretty subtle, but the dpi transform was not correct in
x/yaxis.get_tick_spacingwhen there were subfigures.The new test fails on master with, and you can see that 300 dpi has different list of ticks than 120 dpi
The test is a bit convoluted, but that is because it is tricky to get the ticks to fall right on the boundary where the difference can be seen.