-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add autotickangles property #6790
Conversation
… 90 or -90 degrees. Previously this check only tested 90 degrees.
when tickangles is set to "auto", this array will be searched for the first angle large enogh to prevent overlap between labels
src/plots/cartesian/axes.js
Outdated
@@ -3806,8 +3820,8 @@ axes.drawLabels = function(gd, ax, opts) { | |||
// N.B. during auto-margin redraws, if the axis fixed its label overlaps | |||
// by rotating 90 degrees, do not attempt to re-fix its label overlaps | |||
// as this can lead to infinite redraw loops! | |||
if(ax.automargin && fullLayout._redrawFromAutoMarginCount && prevAngle === 90) { | |||
autoangle = 90; | |||
if(ax.automargin && fullLayout._redrawFromAutoMarginCount && Math.abs(prevAngle) === 90) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
=== 90
doesn't seem like the right condition here anymore. In fact I'm suspicious of this condition (even before this PR, why is it only a 90-degree rotation that can lead to infinite loops? why not a 30-degree rotation?) so I feel like we should get rid of it and just (inside fixLabelOverlaps
) require that if there's a prevAngle
we only choose one with Math.abs(newAngle) >= Math.abs(prevAngle)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to insert my change without having to understand the whole file. So I am not sure what exactly would cause an infinite redraw loop. If I remove the entire if-condition (so the code would always do seq.push(fixLabelOverlaps)
) and set the angle to >= prevAngle
inside fixLabelOverlaps
, this will be okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check my latest commit for this change
Interesting PR. |
Could you help me out with the correct definition here (omitting
|
Let's not set |
Not sure if the last failing test is related to my changes? (test-baselines compare-pixels) |
Yes. It is the side effect of your PR. Please see the diffs in the |
Previously, although I used [30, 90] as default autotickangles, this did not reproduce old images, since the condition for choosing between the two was also different.
Thank you, I introduced the old condition for choosing between 30 and 90 degrees if autotickangles is not provided. Also, I notice that make-baselines did not regenerate the 10.png, the one I edited to test autotickangles. How do I trigger that? |
Please download new |
src/plots/cartesian/axes.js
Outdated
if(angle === undefined) { | ||
// no angle larger than minAngle, just pick the largest angle | ||
angle = autoTickAngles.reduce( | ||
function(currentMax, nextAngle) { return Math.abs(currentMax) < Math.abs(nextAngle) ? nextAngle : currentMax; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of using an angle with "maximum" abs(t)
value, shouldn't we pick the angle with "minimum" abs(cos(t))
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I hadn't thought about angles beyond [-90, 90]. Would be kind of weird to auto-rotate past vertical but I guess no reason to prohibit it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, have changed it to test for minimum absolute cosine.
1d35e92
to
e109cf6
Compare
e109cf6
to
cdae996
Compare
This reverts commit 9473029.
- start with the first autotickangle entry, not 0 - move radian calculation closer to its use
39bfdff
to
7d8e607
Compare
I pushed a small commit that makes the behavior what I wanted: when using Then a couple more to fix colorbar ticks and polar ticks (which both thought they were preventing autotickangles, but they weren't and in certain cases they shouldn't!) @archmoj @my-tien there's still one failing image that I don't quite understand, I can take a look again in the morning, and for some reason I wasn't able to rebuild the schema tonight. Also the same failing jasmine tests as before. But otherwise I think this is good to go from my side! |
Thanks very much @alexcjohnson and @my-tien. |
Nicely completed. |
The new
autotickangles
property can be used to specify a choice of rotation angles for the labels on the x-axis.If
tickangle
is set to "auto", it will be set to the first angle in this array that is large enough to prevent label overlap.Previously, when
tickangle
was set to "auto", plotly would choose between a hardcoded 30 or 90 degrees which is still the default forautotickangles
, so backwards-compatibility is maintained.