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). Exactly. > 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): http://www.w3.org/TR/REC-CSS2/tables.html#height-layout "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 spec. > 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!!! :-) Jeremias Maerki
