https://issues.apache.org/bugzilla/show_bug.cgi?id=44412
--- Comment #16 from Jeremias Maerki <[EMAIL PROTECTED]> 2008-04-29 01:35:11 PST --- (In reply to comment #15) > Created an attachment (id=21718) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=21718) [details] > Illegal empty page inserted because of two consecutive break-before > > I noticed that this change introduces a regression in the handling of breaks. > In the following situation: > <fo:block break-before="page"> > <fo:block break-before="page"> > Some text. Some text. Some text. Some text. > </fo:block> > </fo:block> > only one page break should occur. The empty box introduced by the change now > triggers an additional page break. This used to work well with FOP 0.94. > 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 once again tried to find hints in the spec that the two break-before properties should effectively be merged. But I didn't find anything. In the end, if tables are implemented to merge the break-befores together but the other block-level FOs don't do that, then IMO that's merely a behaviour inconsistency inside FOP rather than a bug in one or the other parts. I believe this needs some more discussion on fop-dev before we do any more about this bug. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
