--- 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)
 --> ( [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
> 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
- 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:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to