-
Notifications
You must be signed in to change notification settings - Fork 120
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
Partition chart text should scale uniformly along sectors/rings #661
Comments
Thanks @markov00 for writing up the issue. It's been on the radar, and @VijayDoshi has made this suggestion as well. It is a good option, and the results are more balanced text heft wise, esp. with one or two layer sunburst/treemap. Branch is pushed soon, glad to have worked on it 👍 The tradeoff is reduced scaling in legibility: a single bad case (eg. narrow box, long word) can yield a small, maybe unrenderably small text for all the subsequent boxes too, even if those could otherwise be rendered. For this reason, and also, not to cause a breaking change, the current PR has The logic currently achieves monotonicity per layer. This is uncontroversial with the treemap as groove texts are bound to be small. For sunburst, it looks preferable too, because otherwise a single, small inner slice can lead to small fonts in all the outer rings. However it can still lead to cases where an outer sector has a larger font than an inner sector of lower value, eg. The per layer monotonicity also means that font size constraints do not get reset for groups. In other words, if there are two top level groups A and B in a two-layer chart, then the font size of a node in Group A can't be larger than any of the font sizes of nodes in Group B that have higher values. There's no constraint for linearity or other proportionality. So it's still possible to have unbalanced texts, eg. if the biggest box is Treemap, also three layers, has storybook knobs too: The current issue and PR response leaves other aspects of "text ink weight perception" unaddressed: text lengths and even the character shapes in the texts impact visual weight. Further, possible improvements might help, but again, there are diminishing returns, so prioritization would be needed:
These would bring improvements in addition to helping with text ink proportionality |
Ensures that font size doesn't overemphasize certain slices just because the text is shorter or there's more horizontal space. It works by constraining the maximum font size for a slice/sector/rectangle to the smallest of the rendered font sizes of slices/sectors/rectangles within the same ring or treemap layer that belong to larger or equal values. Also, adapts the simple hill climbing optimizer to turn font sizing into an O(log(N)) process: bisecting constrained maximization. Improves on type information via removing `any`s and adding generics. fix #661 Co-authored-by: nickofthyme <[email protected]>
# [19.4.0](v19.3.0...v19.4.0) (2020-05-28) ### Bug Fixes * **partition:** consider legendMaxDepth on legend size ([#654](#654)) ([9429dcf](9429dcf)), closes [#639](#639) ### Features * **partition:** enable grooves in all group layers ([#666](#666)) ([f5b4767](f5b4767)) * **partition:** linked text overflow avoidance ([#670](#670)) ([b6e5911](b6e5911)), closes [#633](#633) * **partition:** monotonic font size scaling ([#681](#681)) ([ea2489b](ea2489b)), closes [#661](#661) * **tooltip:** improve positioning with popperjs ([#651](#651)) ([6512950](6512950)), closes [#596](#596)
🎉 This issue has been resolved in version 19.4.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
# [19.4.0](elastic/elastic-charts@v19.3.0...v19.4.0) (2020-05-28) ### Bug Fixes * **partition:** consider legendMaxDepth on legend size ([opensearch-project#654](elastic/elastic-charts#654)) ([20cc6ec](elastic/elastic-charts@20cc6ec)), closes [opensearch-project#639](elastic/elastic-charts#639) ### Features * **partition:** enable grooves in all group layers ([opensearch-project#666](elastic/elastic-charts#666)) ([b1bdfb3](elastic/elastic-charts@b1bdfb3)) * **partition:** linked text overflow avoidance ([opensearch-project#670](elastic/elastic-charts#670)) ([59617db](elastic/elastic-charts@59617db)), closes [opensearch-project#633](elastic/elastic-charts#633) * **partition:** monotonic font size scaling ([opensearch-project#681](elastic/elastic-charts#681)) ([d46767c](elastic/elastic-charts@d46767c)), closes [opensearch-project#661](elastic/elastic-charts#661) * **tooltip:** improve positioning with popperjs ([opensearch-project#651](elastic/elastic-charts#651)) ([61d1d9a](elastic/elastic-charts@61d1d9a)), closes [opensearch-project#596](elastic/elastic-charts#596)
Is your feature request related to a problem? Please describe.
Shortest texts stand out more than longer texts in a treemap or pie chart because their fonts can take up much more space than longer texts. This can distort the represented data when the user gives a quick look without at the chart without giving some time to understand the whole picture.
Check the following examples:
In this case,
Belgium
stands out much more than the Netherlands also if from the data it's the opposite and the difference is very small.In this other case, Asia and Europe on the second layer look much bigger than the United States one.
Describe the solution you'd like
I'm imaging a possible configuration option to allow scaling each font uniformly, from the biggest to the smallest. Each sector should compute its max font size depending on the computed font-size of the previous one.
The text was updated successfully, but these errors were encountered: