On 29.11.2007 18:12:35 Vincent Hennebert wrote:
> Hi,
> Ready for yet another one? Everyone’s welcome to join the game ;-)
> If a table-row element has a forced height, must that height include 
> border-separation and the cells’ borders, or only the cells’ bpd?

The property (!) b-p-d is defined to specify the extent of the
content-rectangle which means border (and border-separation) and padding
do not belong in here. The row-height trait (including border, border
sep, padding) is calculated as described in the CSS spec. I think/hope
that's what I implemented. Your example seems to prove that.

> See the attached pdf. On the left you have a table with one cell, and:
> - border-separation = 6pt
> - border-width of the cell = 2pt
> - block-progression-dimension on table-row = 25pt
> On the right you have a block-container with different forced heights to 
> use as a comparison.
> First case: the row’s height should include border-separation and cell 
> border; thus we have:
>     table bpd = row bpd = 25pt
>     cell bpd = row bpd - border-separation (half before, half after) - 
> border-before - border-after
>              = 25 - 6 - 2 - 2
>              = 15pt
> Second case: the row’s height should include the cells’ borders but not 
> border-separation; thus:
>     table bpd = border-separation/2 + row bpd + border-separation/2
>               = 3 + 25 + 3
>               = 31pt
>     cell bpd = row bpd - border-before - border-after
>              = 25 - 2 - 2
>              = 21pt
> Third case: the row’s height should include neither the cells’ borders 
> nor the border-separation; thus:
>     table bpd = border-separation/2 + max(cells’ border-before) + row bpd + 
> max(cells’ border-after) + border-separation/2
>               = 3 + 2 + 25 + 2 + 3
>               = 35pt
>     cell bpd = row bpd
>              = 25pt
> Now guess what? Xep applies the first case (apart from the fact that it 
> also forgets the half of border-separation belonging to the table’s 
> border). XSL Formatter applies the second case. And FOP (if we assume 
> the currently missing half of border-separation has been fixed) applies 
> the third case!
> There’s nothing about that in the XSL-FO Rec since it explicitly refers 
> to CSS (section 7.15.6, “height”). In CSS2 section 17.5.3, “Table height 
> algorithms" says that “the height [of the table] is the sum of the row 
> heights plus any cell spacing or borders”. Which seems to imply that the 
> row height should not include the cells’ borders and border-separation 
> (third case). 


> The following paragraph about computing the row height talks about the 
> cell’s height but not their borders; however this is contradictory to me 
> since that would lead to situations like on the attached picture if the 
> cells’ borders don’t have the same widths. And I don’t dare to follow 
> the “line box” hyperlink which leads to obscure text about replaced and 
> non-replaced inline and block-level elements.

Ignore the "line box" hyperlink because that's only useful for
vertical-align handling which we currently don't fully support.

It's also important to note again the necessary distinction between
"block-progression-dimension, the property" and
"block-progression-dimension, the trait"! The table's content rectangle
is basically the table grid which includes cell borders and most of the
border-separations but not the table's border(-sep) and padding. I guess
that's also the reason for the XSL spec to mention a "row-height" trait
(but it doesn't really define it).

> There’s a small hint in the XSL-FO Rec which says that the space 
> corresponding to border-separation should be filled with the table’s 
> background color, which would indicate that the row should actually not 
> contain the border-separation.

Based on the description in the spec I consider half border-separation
to be part of the border.

> The behaviour of XSL Formatter looks the most reasonable one; that is, 
> include the cells’ borders in the row-height calculation. That’s already 
> what FOP’s doing when the row height is left to "auto", BTW!

The key part is in the CSS spec (17.5.3):
"The height of a 'table-row' element's box is calculated once the user
agent has all the cells in the row available: it is the maximum of the
row's specified 'height' and the minimum height (MIN) required by the
cells. A 'height' value of 'auto' for a 'table-row' means the computed
row height is MIN."

The problem again is probably the reference from XSL to CSS. And CSS is
sometimes not precise enough. It refers to a "box". What exactly is the
"box"? I'm looking forward to XSL 1.2/2.0 where references to CSS are
hopefully removed. The alternative is only the refinement of the CSS

> Anybody wants to add anything before I send a request for clarification 

Definitely worth clarifying based on your results comparing the three
major FO implementations each behaving differently.

Test suite! Test suite! Test suite!!! :-)

Jeremias Maerki

Reply via email to