"contain exactly" should be a defined term

[nigelmegitt]

From #4938, I noticed the phrase "contain exactly" was used but not defined. I imagine it is intended to mean that it is the smallest size possible that completely contains the margin boxes, but it would be worth being explicit about this, since any extension relative to that size would still contain the boxes.

It is probably implicit that the result is intended to be a simple rectangle, but given that the union of boxes being contained might not be a simple rectangle, we should also make that explicit.

Originated from post by @nigelmegitt in #4938

[frivoal]

How about changing

The content box of each ruby base container is sized and positioned to contain exactly all of its ruby bases’ margin boxes.

to

The content box of each ruby base container is set to the smallest axis-aligned rectangle that contains all of its ruby bases’ margin boxes, ignoring transforms as well as relative and sticky positioning. If the ruby base container is fragmented, this is is determined per fragment.

That would seem to cover it, although maybe "axis aligned" and the bit about ignoring transforms and positioning is overkill.

The part about fragmentation does seem important though.

[nigelmegitt]

I think "axis-aligned" introduces the question of which axis, unless that's already a defined term somewhere.

Ignoring transforms seems tricky to me:

What if the transform rotates all the ruby bases' margin boxes together by some value, say 15º? Then the containing box is also the 15º rotated box, right? Or is it?

What if the transform rotates each ruby base's margin box separately by, say, 30º about the centre of each box? Then the containing box is not rotated but is sized to take into account the rotated base boxes, i.e. it would be a bit bigger, right? (or wrong?)

Seems to me like the requirements are:

1. Derive the inline direction as an angle relative to the 2D rendering plane. I'm not actually sure where this data comes from, and if it needs to have some understanding of transformations being applied.
2. Create a rectangle that fully encloses all the post-transformation child boxes, where that rectangle has two edges parallel with the inline direction calculated at 1. and where every edge shares at least one point with at least one point on an edge of any of the child boxes.

[frivoal]

of which axis

both: horizontal and vertical. i.e. not diagonal. Clearly, I'm confusing things more than helping with that statement then, so let's drop it.

Ignoring transforms seems tricky to me

Doing anything other than ignoring transforms would be hard. transforms don't affect layout in any way, it would be really weird if they did here. They're always applied after the fact. So I don't think it should be controversial to ignore them. I was wondering if it was so obvious that they would be ignored that it wasn't even worth stating. I guess it's not that obvious then, so it does seem worth stating.

[nigelmegitt]

OK that makes things much simpler then, if it is clear that this operation of laying out ruby happens before any transforms, then we need the rectangle that:

• has edges aligned either to the inline or the block progression directions and
• completely (inclusively) encloses all of the ruby bases' margin boxes and
• on every edge, shares at least one point with at least one point on an edge of any of the enclosed boxes