Re: Table cell infinite loop and widow/orphan properties on table

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

At 09:02 AM 4/13/01 +0200, Karen Lease wrote:
>DISCUSSION
>Now before fixing this, I want to discuss using these properties on
>tables. My reading of the XSL-FO CR is that widows and orphans only
>apply to Line Areas in a Block Area. This is in fact the usual
>typographical meaning of these terms. It's true that in sections 7.18.6
>and 7.18.7, the CR says that the properties apply to "block-level
>elements". However the note after 7.18.7 says:
>
>    'In XSL the "orphans" property specifies the minimum number of
>line-areas in the first area   
>generated by the formatting object.
>     The "widows" property specifies the minimum number of line-areas in
>the last area generated by the formatting object.'
>
>That seems clear to me. So I would interpret "block-level elements" as
>meaning fo:block, period. In fact, in chapter 6, the widow and orphan
>properties are only listed for fo:block.

I consider the property listings by FO to be definitive. So I agree with 
you: "widows" and "orphans" are simply not applicable to anything other than 
fo:block, by what I consider to be a non-ambiguous reading of the spec.

Note that the "Applies to" tag in the property descriptions is usually more 
precise if it's an XSL property, for example if you look at the keeps, as 
opposed to CSS2 properties such as these two, where the description is taken 
right from the CSS2 spec.

Also, reading Section 4.5 makes it pretty clear what line areas are intended 
to be, and we know that "widows" and "orphans" apply to line areas only 
(from the XSL-specific part of the property description).

>PROPOSAL
>I therefore propose to stop handling widow and orphan propeties on table
>rows. (NOTE: they can have an effect if we break table cells, because
>they can affect how the cell contents are broken.) Instead, if one
>wants, for example, to force the first two rows to be kept together, one
>can just use keep-with-next="force" on the first row. Similarly, to
>force at least two rows to be together in the last table area, on should
>use keep-with-previous="force" on the last row. Note that this says
>nothing about areas other than the first or last if the table is broken
>into more than two parts. (Strictly speaking, neither does widow or
>orphan, even for block-areas. See above quote.)

I agree, on all points. Because the 2 properties simply do not apply, 
according to spec, to anything other than fo:block.

The multi-part bit about widows and orphans for fo:block is a valid point, 
although when you think about it, for situations where the fo:block 
generates content across umpteen pages and/or columns, since each normal 
area that it generates must occupy its own unique column-reference-area or 
span-reference-area, it's not really an issue.
 
>There is already support for keep-with-next and keep-with-previous on
>table-rows. I will make sure that these function as intended and do not
>lead to the infinite loop problem. In fact, what we must do is _not_
>respect keep properties if the "keep set" in question is too large to
>fit in any column-area.
>
>In the table cell-example, if a sequence of rows which are supposed to
>be kept together will not fit together, and if the first row in the
>sequence is already the first in its parent table-body area, and the
>table-area and all of its ancestors are first in _their_ parent areas
>(ie, the table-area is at the top of the column), then we must "violate"
>keeps, either by putting the last row in the sequence in the next area,
>or by breaking it. This latter decision should depend on the value of
>"keep-together" which isn't yet supported.

Right. I mean, if it doesn't fit then it doesn't fit. :-)
 
>COMMENTS and REACTIONS?
>Please speak up!

Done. :-)

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org