https://issues.apache.org/bugzilla/show_bug.cgi?id=44412
--- Comment #17 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-04-29 02:14:45 PST --- (In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=21718) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=21718) [details] [details] > > Illegal empty page inserted because of two consecutive break-before > > I've looked into this but I'm not so entirely sure if this is wrong. That 0.94 > didn't produce an empty page was more or less a coincidence since an element > list with only a penalty(p=-INF) does not trigger page production. But now > that > the parent fo:block of the block issuing the break-before creates a box(w=0), > a > new page with only a zero-height block area is produced (ID production, > optional borders/padding). The constraints defined in > http://www.w3.org/TR/xsl11/#keepbreak are satisfied. The key part when talking > about break-before is: > "A break-before condition is satisfied if the first area generated and > returned > by the formatting object is leading within a context-area." The spec doesn't > say anything about how the parent FO should behave in such a case. I lean into the direction of merging the breaks. Re-reading the spec, I have to agree that producing an empty page looks like equally correct behavior. I think it also demonstrates why break-before and break-after are non-inherited. If they were, specifying a forced break on the outer block would lead to a new page being generated before/after *each* descendant FO (unless when explicitly reset to "auto") On the other hand, and this is what made me lean towards the merging of both breaks: - the outer and inner block each generate one or more normal block-areas - the break-condition only applies to the first/last of those The break-conditions for the outer and inner block are satisfied in both cases. The only difference is that with the current behavior, the inner block's first normal block area is a child of the outer block's second normal block area, instead of the first. It depends more on whether we consider the outer block to have a descendant empty line area before the inner block's first normal block area. Since I do not believe this to be the case here (default white-space- and linefeed-treatment), I still think merging the breaks is the expected result. If one were to activate white-space preservation, there would be a line with some space characters before the inner block, and a new page would have to be generated, since the inner block's first area would no longer be leading in the context area. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
