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".
>
> 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? ;-)
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...
>> Besides that, mind that the native XSL property 'block-progression-
>> dimension' does not directly apply to table or table-row. That is,
>> specifying block-progression-dimension="100%" on a table or table-row
>> would (and should) not have any effect. Only the CSS-XSL hybrids
>> 'height/min-height/max-height' apply to them. Now, these being CSS
>> properties in origin, I think that either:
>> a) the first rule in 7.3 applies
>> "1. For properties defined in CSS2 referring to the "containing
>> block", the content-rectangle of the closest ancestor block-area that
>> is not a line-area is used."
>>
>> or b), the height property being mapped to XSL's block-progression-
>> dimension (or inline-progression-dimension), the fourth rule applies
>> "4. If the formatting object generating the identified area generates
>> a sequence of such areas, the first area is used for the conversion."
>>
>> I'd put my money on a). Moreover, this is most likely why XSL
So would I.
>> explicitly refers to CSS in its definition of height, since
>> percentage heights for tables and table-rows in CSS are /not/ defined
>> in terms of a containing block --they are undefined altogether :(
>>
>> b) seems to make matters even worse. It would again lead to a
>> circular dependency for some tables that are direct descendants of
>> the flow, since that 'first area' could correspond to the first area
>> generated by the table itself... If not, then it could also be an
>> area generated by a completely unrelated block (=first block in the
>> flow) preceding the table...? Big Shrug indeed!
No, the block area in question would be the normal-flow-reference-area
above. Anyway I don't think there is a circular dependency in any case.
As I understand it, at least.
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
