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 Sorry, if this caused additional confusion. More below... Jeremias Maerki On 28.11.2007 13:21:32 Vincent Hennebert wrote: > Hi Jeremias, > > Jeremias Maerki wrote: > > Hi Vincent > > > > 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. > 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. 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. > 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. > > 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.
