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.
Jeremias Maerki On 28.11.2007 15:20:18 Jeremias Maerki wrote: > 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.
table-indented.fo
Description: Binary data
