Hi Jeremias, Thanks again for your patience :-)
Jeremias Maerki wrote: > 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. So? When a block-container has block children, its content rectangle includes the childrens’ borders, paddings and contents. A bpd explicitly set on the block-container is to be divided among the childrens’ borders, paddings and bpds. > 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. <snip/> >> 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"! What’s the difference? Section 7.15.3: “This property specifies the block-progression-dimension of the content-rectangle for each area generated by this formatting object.” A table-row doesn’t generate any area, anyway... > 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. Sorry, don’t follow you, why are you talking about the table here? > 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. Good point, but which adds to the confusion IMO. See below. >> 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." Of course but on the picture I attached in the previous mail both cells have the same height, yet the row really can’t be like I drew it. The relationship is IMO more complex and involves the cells’ borders, and that’s why the second case (XSL Formatter) looks more logical to me. In my opinion we should play with the cells’ allocation-rectangles (extending to the border-rectangle) instead of their content-rectangles (like implied by CSS when mentioning the cells’ “height”). The height of a row would then be h with h = max(border-before + padding-before + bpd + padding-after + border-after, for each cell belonging to the row) Then the height (content rectangle) of each cell would be modified so that the sum matches h. See attached picture. If the row has an explicit height we would do exactly the same, taking for h the max of the calculation above and of the explicit height. Now this doesn’t answer the question whether the border-separation should be included or not. This is not important when the row height is left to auto, but it is when it is set to an explicit value. The fact that the border-separation should be filled with the table’s background leads to answer no, but the fact that half the border-separation is part of each cell border, like you mention above, would lead to a yes. > 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!!! :-) Pictures! Pictures! Pictures! Vincent
<<inline: row-height_2.png>>
