Undesirable padding behaviour with disparately sized children

[russss]

I'm fairly new to d3, so forgive me if I'm wildly wrong here...

I've got a treemap which looks like this:

Note that the brown category at the bottom right is quite small compared to all the others.

I'd like to add 25px of paddingTop so that I can add titles to these categories, but when I do so, the brown category is unfortunately squashed to 1px high:

I don't entirely understand what's going on here, but it looks like the layout algorithm (I'm using the default in this case, but others are similarly bad) is stealing the same constant amount of padding space from each child, when I guess it should be proportionally taken from (in this case) all of the children in the same vertical column.

[ianstormtaylor]

Running in to this as well, I assumed the padding would be aware enough to not distort the resulting data. Seems like all the Treemap examples on Observable suffer from this?

Looks like this was brought up in #19 and #20 but forgotten.

[mshd]

@ianstormtaylor @russss have a look at https://github.com/codeledge/entitree-flex

[Santas]

A two-pass approach might be an acceptable if imperfect solution: compute the layout without padding, compute the area lost to padding for each cell, add this to the value for the cell, and then recompute the layout.

We do something similar to what @mbostock suggested in #19. We call treemap twice and hack around the issue by reordering some nodes to better fit which is not ideal, but works for our use case as a workaround.