https://issues.apache.org/bugzilla/show_bug.cgi?id=44412
--- Comment #18 from Vincent Hennebert <[EMAIL PROTECTED]> 2008-04-29 02:47:08 PST --- (In reply to comment #17) > (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] [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. I agree, and for one time I’d say the specification sounds clear to me. The name ‘break-before’ is given to the property because it corresponds to the common understanding. But the description doesn’t talk about breaks at all, but instead about leading areas (see the section Jeremias cited). Technically speaking, an empty page wouldn’t break the spec since the first areas generated by both the outer and the inner blocks are leading within the page (more precisely the ‘normal-flow-reference-area’). But a valid layout can be created /without/ generating this empty page, which makes it preferable. I think this rule should be taken with the same spirit as for space resolution, which allow stylesheet writers to specify spaces for every element without worrying about the context in which they appear (is the paragraph preceded by a section title, a list, another paragraph, etc. where the space-before would differ in each case). > 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. Very good point. Although I think it would go against comment #4 and give a jusitication for putting the before border of the enclosing block on the new page, along with the inner block, in attachment #21531. I think our best bet is to ask for clarification on [EMAIL PROTECTED] Will do in a couple of days if nobody else chimes in. Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
