--- Comment #16 from Jeremias Maerki <[EMAIL PROTECTED]>  2008-04-29 01:35:11 
PST ---
(In reply to comment #15)
> Created an attachment (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 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

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to