Hi Jeremias, I think we’re making progress ;-)
Jeremias Maerki wrote:
> On 28.11.2007 17:28:04 Vincent Hennebert wrote:
>> 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.
>
> Right, there seems to be something wrong on the right side. I actually
> didn't pay attention to the right side at all when I built the example.
> I also only specified margin-left but no margin-right. But even with
> margin-right set to 0pt, the table bleeds out of the main reference area,
> but that's (probably) because of a priority conflict between the
> inline-progression-dimension property (width=100%) and the indents which
> restrict the size of the content rectangle. But reading again the CSS
> text for fixed table layout (which is active in this case), I would say
> that the end-indent is really overruled here and that FOP behaves
> correctly in this case. You'd have to specify width="100% - 2 * 5pt" for
> the second table to be like the block above the second table. So this
> behaviour is correct IMO.
Studying the spec more carefully I come to the same conclusion as you,
but not the same explanation.
First, width doesn’t apply to fo:block, so what I said above (“it should
then also stick out in the margin”) is non-sense and damn me for adding
yet another imprecision. The following:
<fo:block-container margin-left="0pt" width="100%" border="solid 5pt blue">
<fo:block>This is a block!</fo:block>
</fo:block-container>
<fo:table margin-left="0pt" margin-right="0pt" table-layout="fixed"
width="100%" border-collapse="separate" border="solid 5pt red">
leads to the same amount of content sticking out in the margin, both for
the block-container and the table. I think the explanation is to be
found in the XSL Rec instead of CSS since width is mapped to either ipd
or bpd. And section 5.3.4, “Overconstrained Geometry” gives the answer.
In the present case end-indent is adjusted to a negative value (-10pt).
At least that one is clear!
<snip/>
>>>>>> 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.
>
> No, take a look at the graphic in http://www.w3.org/TR/xsl11/#area-stackblock.
> space-start = start-indent - border-start - padding-start.
>
>> 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.
>
> There's no way around mixing the two if you want to convert from one
> world to the other. In the above equation that is:
> trait = property - property - property
So you assume that the border-start, padding-start and start-indent on
the graphics are properties, while space-start would be a trait? Weird.
Anyway, if we consider the formula deducted from the graphic:
space-start(trait) = start-indent(property) - border-start(property) -
padding-start(property)
and insert it into the formula that I re-phrased:
xa = start-indent(property) + start-intrusion-adjustment -
border-start(trait) - padding-start(trait)
- space-start(trait)
= start-indent(property) + s-i-a - border-start(trait) -
padding-start(trait)
- start-indent(property) + border-start(property) +
padding-start(property)
where xa is the x-coordinate of the allocation-rectangle’s start-edge.
If we forget writing mode changes we have the following relation with
the content-rectangle:
xa = xc - start-indent(property —start-indent is not a trait!)
In the majority of cases the formula above will simplify to the
following:
xa = start-intrusion-adjustment
thus, for xc:
xc = start-intrusion-adjustment + start-indent
which would indeed make border and padding stick out in the margin,
which is FOP’s behaviour as well as all the other FO renderers I’ve
tested, which would be ok (and invalidates my rephrased sentence :-\).
In the case of separate border model for tables we would have a slight
difference between border-start(property) and border-start(trait):
border-start(trait) = border-start(property) + border-separation.i-p-d / 2
In that case we would have
xa = start-intrusion-adjustment - border-separation.i-p-d / 2
That’s the only reason why it would make sense to keep the formula for
xa in its original form, instead of having the simplified version that
applies to all cases but tables with the separate model. Although I’m
98% sure that the writers weren’t having that in mind when writing it...
And still, some clarification about when traits and properties should be
used would be welcome in my opinion.
And that means that the half of border-separation associated to the
table’s border should lie in the margin, unlike XSL Formatter is doing.
<snip/>
>> 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).
>
> As indicated above, you were right to notice a mistake on my side here.
> Your graphic is correct. Padding indeed lies between half the
> border-separation from the table and half the border-separation from the
> table-cells.
So where should the outermost grid boundary line lie? This is consistent
only if it coincides with the table’s padding, and thus has the sickness
(oops... thickness) of the padding.
>> 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?
>
> You got it right intuitively by adopting the normal box model.
>
>> 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.
>
> I don't have a working trial license of XSL formatter anymore so I can't
> check what exactly you mean. Anyway, after considering your input and
See the simulation on the attached PDF. The formula for the table width
would not be the same in each case...
<snip/>
Vincent
border-separation.pdf
Description: Adobe PDF document
