[Question] nodeLabels.placement H_LEFT vs H_CENTER influences child node placement

[frankbenoitbosch]

I am using https://rtsys.informatik.uni-kiel.de/elklive/examples.html 0.9.1

node default {
    algorithm: layered
    label "Default" {
        layout [ size: 43, 15 ]
        nodeLabels.placement: "INSIDE V_TOP H_CENTER"
    }
    node n1 { 
        label "1" {
            layout [ size: 8, 5 ]
            nodeLabels.placement: "INSIDE V_TOP H_CENTER"
        }
    }
    node n2 {
        label "2" {
            layout [ size: 8, 5 ]
            nodeLabels.placement: "INSIDE V_TOP H_CENTER"
        }
    }
}

Now when I change the label "Default" placement to H_LEFT it is positioned left as expected.
But the placement of the child nodes 1+2 is shifted to the right by the width of the label:

node default {
    algorithm: layered
    label "Default" {
        layout [ size: 43, 15 ]
        nodeLabels.placement: "INSIDE V_TOP H_LEFT" // << changed here
    }
    node n1 { 
        label "1" {
            layout [ size: 8, 5 ]
            nodeLabels.placement: "INSIDE V_TOP H_CENTER"
        }
    }
    node n2 {
        label "2" {
            layout [ size: 8, 5 ]
            nodeLabels.placement: "INSIDE V_TOP H_CENTER"
        }
    }
}

I expected that only the label shall be moved to the left, but the position of the child nodes not to change.
Is this a bug? Or shall this be done differently?

[frankbenoitbosch]

Or is it more like, the label does only give information to ELK to define an area for the labels and an area for children.

When there are only labels with H_CENTER, then no side area is for labels is defined, only the top area.
A H_LEFT activates the top-row and left-column for labels, hence all children go to the right.

When I want the left aligned label and the child area not shifted right, I use H_CENTER and draw the label nether the less left aligned by adjusting the coordinates as needed.

Is my understanding correct?

[soerendomroes]

You seem to be correct. In my understanding, setting the nodeSize.options ASYMMETRICAL should solve this problem, but apparently it does not, as seen here.