Hi Jeremias, Thanks for your patience... but I’m still not convinced ;-)
Jeremias Maerki wrote: > For illustration I have attached an FO file that shows different > scenarios with some explanations. This renders correctly in FOP 0.94. > There's really no mistake anywhere that I can detect. Well I see two problems: - the second table goes too far in the right margin. IIUC the inner edge of the border-end should coincide with the region-body. Or this is the other way around: the layout of the table would be ok but then it would be wrong for the previous block when adding width="100%" on it; it should then also stick out in the margin. By reading the rule for percentage on IPD I’m suddenly not so sure anymore. - there is still missing half of the border-separation around the row of the last table, should it be in the margin or not. >> Oh, stupid me! Everything's alright like it is. I didn't notice that >> there is a margin="0pt" in the test case. With a border of 5pt, that >> sets the start-indent to "5pt" and that's why the border is inside the >> content rectangle of the main reference area. >> >> margin="0" has a complex mapping to start-indent. margin >> is not taken directly for indent calculations. It's always mapped to >> start-indent. And we're only working with start-indent internally. See: >> http://www.w3.org/TR/xsl11/#refine-margin-space-indent Indeed, you’re right. <snip/> >>>> Looks like you uncovered one of my past mistakes. Looking again at >>>> all >>>> this stuff, I have to agree that the table's outer border has to lie >>>> outside the table's content-rectangle, and that content-rectangle is >>>> inset relative to the parent reference area by start-indent. Like it >>>> happens with fo:block. Right now, fo:table (border-collapse=separate) >>>> behaves differently from fo:block. There's only a difference here if >>>> border-collapse is collapse, but not for the "separate" case. >>>> >>>> The stuff about the "outermost grid boundary line" is covered by the >>>> normal FO box model with the speciality that fo:table has no padding. >>>> http://www.w3.org/TR/xsl11/#area-stackblock >>> Well I’ve never really understood that section since, to my knowledge, >>> space-start doesn’t apply to block areas. >> I suspect you've fallen into the property vs. trait trap. start-indent >> is a trait which is indirectly set through the start-indent property on >> block-level FOs. The section is mainly about areas and therefore traits. I admit that I made some confusion between trait and property. But re-reading the spec, the question remains: start-indent is not a trait (doesn’t appear in section 4.2.2). space-start is a trait although it’s specified nowhere how its value should be set for block areas. I assume the start-indent property directly maps to the space-start trait. But then the formula still doesn’t make sense, since it is mixing traits and properties! If we consider that traits have already been mapped, then the start-indent and the space-start in the formula cancel each other and lead to the simplification I gave. >>> The formula makes sense only >>> by replacing space-start with start-indent. The sentence would be >>> rephrased like this: >>> “the start-edge of its allocation-rectangle is parallel to the >>> start-edge of the content-rectangle of R (where R is the closest >>> ancestor reference-area of B), and offset from it inward by >>> a distance equal to the block-area's start-intrusion-adjustment (as >>> defined below), minus its border-start and padding-start” >>> Since (assuming writing modes are the same) the start-edge of the >>> content rectangle is offset from the start-edge of the allocation >>> rectangle inward by start-indent, that leads to a sensible result. Do >>> you agree? >> Sorry, I don't get it. First, you rephrase the spec but go back to the >> explanation the spec gives in your comment afterwards. Which explanation? >> Anyway, your >> rephrased sentence sounds wrong to be as it only takes border and >> padding into the calculation but not the effects from >> start-indent/margin-left. Note that this sentence mentions the allocation-rectangle, whose start-edge is offset outward from the start-edge of the content-rectangle by the start-indent. So, indirectly, start-indent plays in the calculation. >>> So according to you the outermost grid boundary line should coincide >>> with the content rectangle? In which case, in addition to the table’s >>> border, half of the border-separation should lie in the margin. This is >>> also my interpretation but that’s not what XSL Formatter is doing. >> No, half the border-separation lies inside the content-rectangle. The >> border lies outside the content-rectangle. Or in other words: for the >> separate border model, the border-separation is part of the >> content-rectangle of the table, but the table's outer border is not. >> >> The specification is maybe a little unlucky since it uses the term >> "border" for border plus border-separation. But it specifies exactly >> where the two parts of the "border" will lie. Does it?! Actually your use of padding in your examples just adds a parameter to the equations that I didn’t think of... Re-thinking about it my opinion is that the only correct interpretation is the following: for tables with the separate border model the borders (traits) differ from the common case and are made of two components: - the border property specified on the table; - half of the border-separation. If we consider that the formula above, applying to areas, is using traits then that means that half of the border-separation should lie in the margin, and the other half in the table’s content rectangle as it is associated to cells. If the formula above refers to properties, then that half of border-separation should not lie in the margin as it would not be included in the calculation. In the area tree the table’s padding would be inserted /between/ the two halves of border-separation (see attached picture, too confusing to just make ascii-art). Still, this contradicts with section 6.7.3 (fo:table) of the spec, which doesn’t say where the table’s padding should lie. Indeed it says: “The first [border component], which is placed with the inside edge coincident with the outermost table grid boundary line, has the width of half the value for the "border-separation" property.” But in the description of table-cell (section 6.7.10), it says: “The first [border component], which is placed with the outside edge coincident with the table grid boundary line, has the width of half the value for the border-separation trait.” And what about the padding? We could resort to user expectations, but the fact is I’m not sure what I would be expecting as a user... Perhaps the behaviour of XSL Formatter (not put half of the border-separation in the margin) is the most reasonable one. >>>> Out of this follows: The following test cases have to be revisited: >>>> table_border-collapse_separate_border-spacing_1.xml >>>> table_border-collapse_separate_border-spacing_2.xml >>> That’s quite strange because not specifying any margin on the table, you >>> get the outer border in the margin (but the border-separation is >>> currently not taken into account —indeed half of it is missing in the >>> table’s outer border). >> Yeah, that's where I noticed my mistake (the one of today). But if you >> remove the margin, that simply resets the start-indent to its inherited >> value which moves padding and border outside the visible area (or rather >> the content rect of the main reference area. >> >>> As soon as you specify margin=0 like in the above >>> testcases the layout goes wrong. Hmmm... >> No, it's actually right. I seem to have designed the test that way. Now >> that I've seen that I used "margin", everything's clear again. Agreed now, apart from the fact that half of the border-separation is missing. Vincent
<<inline: separate-border.png>>
