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


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


<<inline: separate-border.png>>

Reply via email to