Vincent Hennebert wrote:
Chris Bowditch a écrit :
Andreas L Delmelle wrote:
<snip/>
The Rec in all its glory! :)
I wonder what this means for tables that don't have a block-container
parent. Note that, since a block's b-p-d can't be specified, that
leaves only block-container as a possible and reliable base 'block-
level FO that generates the closest area ancestor'. If there is no
such block-container, the behavior of percentages would again be
undefined. If there's only a parent block, then this would create a
circular dependency, as you point out...
I don't think there is a circular dependency:
XSL 1.1 says for percentages in block-progression-dimension:
The percentage is calculated with respect to the corresponding dimension
of the closest area ancestor that was generated by a block-level
formatting object. If that dimension is not specified explicitly i.e.,
it depends on content's block-progression-dimension), the value is
interpreted as "auto".
Which I understand as changing the "n%" value of b-p-d for the current
object to "auto". So on Andrea's example:
<fo:table-row>
<fo:table-cell number-columns-spanned="{all}">
<fo:block-container block-progression-dimension.optimum="100%"
block-progression-dimension.minimum="0pt">
<fo:block> </fo:block>
</fo:block-container>
</fo:table-cell>
</fo:table-row>
The height of the fo:block-container is 100% of the height of the
fo:table (the closest ancestor generating a block-area). As for fo:table
the only sensible value is "auto", then the height of this very
block-container is changed to "auto".
I agree with Vincent's interpretation here. When the spec is unclear,
common sense should prevail. Just saying percentage heights are not
supported unless inside a block-container is not good enough IMHO. And
if a common sense approach can't be agreed upon then an e-mail should be
sent to the editors list requesting clarification.
In the case where fo:table is a child of fo:block or fo:flow isn't the
nearest ancestor reference area the fo:region-body? Whose bpd will be
known.
To be precise, the nearest ancestor is the normal-flow-reference-area in
which the table relies, which has the size of its parent
span-reference-area, whose size generally is the size of the
main-reference-area (unless there are several spans) which generally has
the size of the region-body (unless there are before-floats or
footnotes) (see 6.4.14 fo:region-body). Follow me? ;-)
Yes and I agree.
So yes the bpd should be known, unless there are several spans in which
case we can surely imagine a whole bunch of tricky situations with a mix
of auto and percentages, leaving the bpd undefined...
Thats right, so the only case thats not supported then is percentage
heights on FOs on a page with multiple span areas. I think that is an
acceptable limitation from a user perspective.
<snip/>
Does anyone else think this discussion should be moved to fop-dev?
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
