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:
> 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.
> > >
> > 
> > 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.

Description: Binary data

Reply via email to