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?
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.
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.
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!
Anybody wants to add anything before I send a request for clarification
on [EMAIL PROTECTED]
Thanks,
Vincent
row-height.pdf
Description: Adobe PDF document
<<inline: row-height.png>>
