2

When creating a treemap structure with boxes, boxes with a text that is larger than the box itself are not drawn.

Below the same treemap is show twice: once with text, once without text.

treemap with text

image without text

How do I prevent this from happening?

Community
  • 1
  • 1
Sam Van Battel
  • 123
  • 6

1 Answers1

1

I'm pretty sure this can't be prevented. The reason is that the box sizes have hard constraints on their sizes (the size is as meaningful as the height of a bar in a bar chart), so they can't grow with the size of the enclosed text.

To fix this you could generate shorter labels (removing all the vowls and truncating them) and showing the full label as a tooltip? Or you could have a box with a label in it on the side which contains the currently hovered box?

Jurgen Vinju
  • 6,393
  • 1
  • 15
  • 26
  • How would I go about showing a tooltip? I can't seem to find anything about that in the rascal reference. – Sam Van Battel Dec 15 '19 at 19:35
  • See this other so question https://stackoverflow.com/q/20299595/1768565 – Jurgen Vinju Dec 15 '19 at 19:46
  • I can't comment yet on the other question (not enough reps on stackoverflow), but the tooltip from the other question works. However, it is pretty laggy and slow. – Sam Van Battel Dec 15 '19 at 20:54
  • From the docs: "If the treemapping algorithm assigns a size to a figure that is smaller than its minimal size then a box (with the same properties) is drawn instead of the actual figure." So this is fundamentally incorrect. The docs really need a serious update/upgrade. – Sam Van Battel Dec 15 '19 at 20:56
  • I agree the documentation needs work, but in this case doesn't it work exactly as described? – Jurgen Vinju Dec 16 '19 at 07:47
  • As I see it: A box is a figure. the treemapping algorithm assigns a size to that box that is smaller than its minimal size. The docs state that, in this case, a box will be drawn instead of the original figure. However, the result is that nothing is drawn, so the documentation contradicts the result. – Sam Van Battel Dec 16 '19 at 08:49
  • Ah I understand the confusion. "Nothing" would be a white background or something. In this case a "box" is drawn with the same background color as the text figure would have had. That's what the documentation tries to say. That box may look like nothing to you but it's an empty box. – Jurgen Vinju Dec 16 '19 at 09:03
  • Why would it draw a box with the same background as the text figure would have had? The figure that couldn't be drawn was the (red) box, because it couldn't resize any further (due to another figure that is contained within). So the replacement box should have the same properties as the (red) box. – Sam Van Battel Dec 16 '19 at 09:29
  • And in case it somehow only checks the lowest level figure that couldn't be drawn (in this case the text figure), it does not use the same properties for the replacement box: I've checked and added a fillcolor and border to the text properties, and still the replacement box is white/transparent, borderless and empty. (while the docs state that "a box (with the same properties) is drawn") – Sam Van Battel Dec 16 '19 at 09:31
  • 1
    I don't know or understand exactly which figure could not be drawn. If you think there is a bug, please submit an issue report on GitHub? We'll look into it. This looks like a complex issue then and the figure code Maintainer is currently busy with other stuff so it may take longer to fix than your course takes. Please, if you have time do submit a bug report? – Jurgen Vinju Dec 16 '19 at 09:46