Consider automatically detecting optimal word size in Tag Cloud

[thomasneirynck]

Tag Cloud requires users to set the word size. The current behaviour is, that if not all the words can be fitted on screen, they will be discarded.

Consider dynamically setting the best font range, so all words would fit on screen.

[rashmivkulkarni]

When I try and generate a tag-cloud report it seems like it omits some tags int he report and shows the message The container is too small to display the entire cloud. Tags may appear cropped or be omitted.
This happens only when I generate a report as the container seems small to fit all the Tags.
Attaching a sample tag cloud report to show the error message

[pieterjanverbruggen]

+1 for this issue, I also have it in the following scenario:

1. A word cloud of 15 items is fully displayed - everything looks fine and is readable
2. I select one of the words in the word cloud as a filter
3. The word cloud updates to no values with the message the container is too small
4. When I open the word cloud in full size the value is shown, but not in the original container.

This is surprising to me as it is clear from step 1 that there is a font size which would allow the term to fit the container. See the screenshots attached.

[monfera]

Word cloud is added to elastic-charts PR and story, which also logs into the console as an example, if there's not enough space.

The behavior is that it stops adding words once it ran out of room, so the order supplied is important.

The automatic font sizing would be somewhat difficult:

• there's no lower bound which guarantees full layout, except 0..1 points, ie. deteriorates into unreadability
• there's no areal estimation, so even if there's leeway with the font size, it'd require a logarithmic search, laying it out with decreasing minimum font size, and/or decreasing maximum font size (tweaking min vs max font sizes alone is not a self-explanatory tradeoff)
• this iteration is atop of the already iterative layout algo, which might operate on a potentially large, unbounded number of words, so it may lock the UI without safety limits or farming it out into a web worker
• if the font sizes can go very low, the holes and crevices of larger letters will be full of small words :-)

So all in all, not trivial, and the upcoming behavior (still shows as much as it can) may already be helpful.

My proposal is, let's close this issue if the elastic-charts take of rendering the first N that fit is OK, or if iteration is still needed, let's link it to the Kibana issue(s) dealing with word cloud parametrization eg. Lens and TagCloud and add a downstream issue for implementing the iteration in elastic-charts

[stratoula]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.