On 29.11.2007 18:12:35 Vincent Hennebert wrote:
> 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
> on [EMAIL PROTECTED]
Definitely worth clarifying based on your results comparing the three
major FO implementations each behaving differently.
Test suite! Test suite! Test suite!!! :-)