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

Reply via email to