-
-
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
Legend overlaps since 1.11.0 #771
Comments
Reproducible example here: http://codepen.io/etpinard/pen/dXZQGP Is this really a bug though? To me the behaviour in That said, something is up with legend positioning. Take a look at http://codepen.io/etpinard/pen/mELQPA - even by setting I doubt that this affects only pie charts. The legend drawing code is pretty trace type agnostic. To be investigated. |
Thanks for creating the reproduction. Curious - in my application when I had a too-long legend, it simply My suggestion would be to enable word-wrap and allow the developer to On 25/07/2016 18:38, Étienne Tétreault-Pinard wrote:
|
This comment has been minimized.
This comment has been minimized.
Another report in #840 From @odow
From @n-riesco
|
I've been looking into the issues with legend placement and auto margins in horizontal mode, and I have found a few things. https://jsfiddle.net/Lfxvm3zz/2/ It looks like Plotly goes through a few steps when placing the legend:
Because the margins are checked before the scrollbar clipping is done, it always considers the full height of the legend. This height can easily be taller than the viewport if you have a large number of traces with any long trace names, which will cause Plotly to not be able to include the legends height in the margin spacings. In these cases, no margin is added and the legend is pushed up onto the plot, then clipped at the height of the plot, covering it almost completely. I think a maxHeight attribute or some other method of deciding how tall the legend should be allowed to be may be needed for horizontal mode legends so that it can be included in the margin calculations. |
Hi all, Related to this "overlapping legend when placed at the bottom" problem, Have you guys considered providing a JS method that returns each item in the legend and the chosen colors ( Is that a possibility? |
I have got a similar issue: When the legend text is too long, it also overlaps. You can change the "name" of the trace to see the difference. But it'll be better if Plotly can provide some function to tell this... Thanks! |
This is still a problem on latest. I also have a pen that reproduces the issue in a manner similar to how it manifests in my project, where some plots have a large number of legend items. If you resize the window to make it narrower, you will see the legend jump around between being well-behaved, ending up above the chart or obscuring the chart entirely. My space constraints are pretty lax, but I wasn't able to find a suitable workaround. I was hoping to find some kind of setting that would do something like preserve a fixed size for the plot area and then use up as much additional space as it needs for the legend, but such an option doesn't appear to exist. |
As is becoming evident, this is a general issue with any Plotly chart rendered in a small container. For what it's worth, this issue is being 'wrestled with' in downstream projects, e.g. like this: |
Basically, there isn't much reason I can think of for a legend to overlap the chart. It basically defeats the purpose of the visualization, particularly when the legend obstructs a significant portion of the chart. |
Related to: Other people struggling with legend overlap: |
FWIW my workaround ended up being providing the users a button that doubles the height of the chart on demand. Pretty lame, but easier to implement than a drag-to-resize feature. I couldn't find an effective way to automatically determine whether the plot in an unusable state, so I made it the user's problem instead (luckily that's acceptable for my use-case, but it still rubs me the wrong way). |
In my use case (see #4018), regardless of the problem of the legend it self (whether it should overlap the plot or not), the plot area size computation is broken. We clearly see in the second pen that even though the choice is made to display the legend over the plot, the plot area is computed like the legend was outside. Could this be fixed before this whole issue ? Regarding the issue, I would agree with @brylie in this comment. And in the case the user still wants to display the legend over the plot, he/she should be able to do it by setting the legend positioning options. |
Possible workaround(taken from several SO threads and GH issues) in server.R
in ui.R
It's super hacky, but an approach similar to above (mostly after playing around with different width and height of the box()) fixes 95% of the issues in our case. |
Hi all, first I'd like to apologise for not taking care of the numerous bugs reported here sooner. I'm happy to say that the next minor release (v1.50.0) should fix the reported issues. At the very least, we will offer workarounds, most likely by adding a new legend attribute.
Note that some of the work here overlaps with PR #3024 that we should close, by the way. Moreover, the work done here will make implementing #1340, #3151, #1199 and #960 (to name a few) much easier. In brief, two things made fixing these bugs pretty tricky:
Both points could be considered wrong and simply dropped, but I chose to honour them (at least until a major bump). Going through the reported examples: https://codepen.io/etpinard/pen/dXZQGP shows the legend overlapping the plot area. Here, the constrained legend x position is wrong. See https://codepen.io/etpinard/pen/VwZjjpm which shows both a non-constrained version (using new attribute tentatively named https://codepen.io/odow/pen/mEarpy shows a legend with a bad constrained y position and a bad computed height. See fixed version in https://codepen.io/etpinard/pen/KKPMMqb https://jsfiddle.net/Lfxvm3zz/2/ does not honour https://codepen.io/Nauss/pen/MMBdrw shows a very bad case of a wrong x position constraint. Fixed in https://codepen.io/etpinard/pen/GRKqqQO https://codepen.io/anon/pen/KbZbRv?editors=0010 show bad behaviour on window resize, see fixed version here: https://codepen.io/etpinard/pen/MWgeeQM From #2337 https://jsfiddle.net/6oq39dpy/6/ shows a messed up y constraint. Fixed in https://jsfiddle.net/2dm3y158/ From #2131 https://codepen.io/etpinard/pen/ZaEEyL?editors=0010 and https://codepen.io/plotly/pen/gvEaRK show bad behaviour for horizontal legends with You can also check out the image diffs off 7d0a524 for more before/after comparisons. cc @plotly/plotly_js |
Now fixed with d568610 (bundle: https://48124-45646037-gh.circle-artifacts.com/0/dist/plotly.min.js) -> https://jsfiddle.net/yuwfnj7t/ |
Awesome, thanks @etpinard! Can't wait to get these fixes and remove my unfortunate workaround. |
- see #771 - introduce measures _maxHeight, _maxWidth and _effHeight to track margin pushes, scrollbox and horizontal row wrapping - simplify (and fix) legend (x,y) constraint into graph width/height - introduce some l,r,b,y "max" margin-push logic - update baselines! + from previous "new legend mocks" commit + and `horizontal_wrap-alll-lines` which now spans the graph's width
- see #771 - introduce measures _maxHeight, _maxWidth and _effHeight to track margin pushes, scrollbox and horizontal row wrapping - simplify (and fix) legend (x,y) constraint into graph width/height - introduce some l,r,b,y "max" margin-push logic - paves way to expose legend `maxheight` and `maxwidth` - update baselines! + from previous "new legend mocks" commit + and `horizontal_wrap-alll-lines` which now spans the graph's width
- see #771 - introduce measures _maxHeight, _maxWidth and _effHeight to track margin pushes, scrollbox and horizontal row wrapping - simplify (and fix) legend (x,y) constraint into graph width/height - introduce some l,r,b,y "max" margin-push logic - paves way to expose legend `maxheight` and `maxwidth` - update baselines! + from previous "new legend mocks" commit + and `horizontal_wrap-alll-lines` which now spans the graph's width
- see #771 - introduce measures _maxHeight, _maxWidth and _effHeight to track margin pushes, scrollbox and horizontal row wrapping - simplify (and fix) legend (x,y) constraint into graph width/height - introduce some l,r,b,y "max" margin-push logic - paves way to expose legend `maxheight` and `maxwidth` - update baselines! + from previous "new legend mocks" commit + and `horizontal_wrap-alll-lines` which now spans the graph's width
- see #771 - introduce measures _maxHeight, _maxWidth and _effHeight to track margin pushes, scrollbox and horizontal row wrapping - simplify (and fix) legend (x,y) constraint into graph width/height - introduce some l,r,b,y "max" margin-push logic - paves way to expose legend `maxheight` and `maxwidth` - update baselines! + from previous "new legend mocks" commit + and `horizontal_wrap-alll-lines` which now spans the graph's width
Great job @etpinard. |
Hi @TUSHAR4541 - I wasn't planning on adding that for the next release (v1.50.0), but it should be fairly easy to add eventually. You can subscribe to #1340 for the latest updates. |
- see #771 - introduce measures _maxHeight, _maxWidth and _effHeight to track margin pushes, scrollbox and horizontal row wrapping - simplify (and fix) legend (x,y) constraint into graph width/height - introduce some l,r,b,y "max" margin-push logic - paves way to expose legend `maxheight` and `maxwidth` - update baselines! + from previous "new legend mocks" commit + and `horizontal_wrap-alll-lines` which now spans the graph's width
- when one sets autoexpand to false, fullLayout.margin are honoured no matter how big the legend gets. In this case, (I'd argue) the legend should NOT move from its provided (or default) (x,y) position to make it fit on the graph. - if some users want the legend to auto-expand the margin while keeping the provided/default (x,y), we could eventually add a `legend.fitinside` boolean attribute
This appears to be a regression introduced in 1.11.0 - probably by: #53 and is still evident in "latest;
In 1.10.2 and earlier, when a legend was too wide and would overlap a pie chart, the legend would not show.
Since 1.11.0, the legend is shown overlapping the pie chart.
This can be replicated very easily with the following data declaration (default everything else):
Of these two behaviours, not showing the legend is preferred. The ideal solution (feature request I guess) would be to scale the legend to the a suitable non-overlapping size, then wrap the text within that.
The text was updated successfully, but these errors were encountered: