Fix annotation autorange on category axes#1791
Conversation
- fixes annotations autorange - does not appear to have any unwanted side-effects.
|
Nice and simple, and this actually seems like it's the logical way for But did that mock fail before the patch? The coordinates that lead to the shape and annotations bumping out the autorange didn't come from category names. For annotations we can use a category that's already in the data and let the text box or arrow add extra pixel padding, for shapes it seems like we may need to use a category that's not in the data, so |
- same as what Axes.coercePosition does at the defaults step for other axis types - post #1748, we need to handle this at the ax.r2c as the categories are only known after the calc step.
Great.
Layout-image-induced autorange bumps aren't a thing ye (seet #1111) and the
Oops, I messed that up when I added arrows to the mock. Fixed in -> e4aa7a3
Good call here. That actually uncovered another bug. Done in -> aaf12ba Bonus: annotations and shapes with invalid category coordinates were broken too. Fixed in -> 0758b3b |
|
Beautiful. Gotta love it when all these extra edge cases pop out on fixing related issues. |
fixes #1768 by making the category axes
setConvertmethods a bit more of a mess. Note that annotation autorange usesax.r2c.Oh well, with this patch here, it seems like all the cases are covered.
Together with #1748, we now have working category annotations on first draw and on pan/zoom 🎉 :
By the way @alexcjohnson I chose to add a new mock in f5c0382 instead of appending
annotation-autorange.jsonto test shapes on category axes as well. I hope you don't mind.