On 30.11.2007 11:54:38 Vincent Hennebert wrote: > 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.
With bpd on a table for example, I mean the table's border and padding are not included. I don't talk about its children. > > > 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... No, but the value is used in the formulas to calculate the BPDs of the area generated by the table-cells or for backgrounds. > > > 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? After re-reading, me neither. > > 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. I thought we're already doing that. > 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. Of course, border-separation needs to be included for calculating the row-height trait but it's not important in the actual "row height" (note the missing dash) calculation, because the border-separation is simply added at the very end to get row-height. In other words, as long as you're working with the height properties you can leave border-separation aside. So your row-height_2.png is ok but it ignores border-separation. If border-separation is included, there should be a "row-height" measurement which includes half border separation twice. > 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 way border-separation is handled painting-wise doesn't say anything about how it is to be used in calculations, does it? The spec saying that it's part of a border does on the other side. > > > 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! Yes, but we should have a more complete pictures. Yours help but they are still incomplete or only show part of the problem IMO. I think it would be easiest to spark a discussion on xsl-editors by providing a simple but comprehensive example which can be used to show how different the various implementations do the calculations. Otherwise, we're wasting a lot of time here with speculation. Jeremias Maerki
