--- 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]
> > 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
> the parent fo:block of the block issuing the break-before creates a box(w=0),
> 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
> 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
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.