--- Comment #19 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-04-29
03:37:01 PST ---
(In reply to comment #18)
> (In reply to comment #17)
> > 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 [details].
If the construct is
<fo:block border="4pt solid black">
case #1: Supposing the outer block's first area is already leading in a context
area, no extra page-break needed. No real issue, if I'm correct.
case #2: If the outer block's first area is not leading in a context area, the
break-condition for the inner block would not be satisfied if its first area is
a descendant of the outer block's first area. Generation of a second block area
is necessary. The border-traits do apply to both generated areas for the outer
block, but given a default conditionality of 'discard', the border-before
should only appear on the first area.
In the example, we're dealing with case #2, due to the preceding block.
Jeremias' conclusion in comment #4 seems correct to me: the bug is that the
border-before is missing on the first page.
If conditionality is set to 'retain', and the border is not rendered on the
second page, that would also be a bug.
Turning on white-space-preservation for the outer block would make no real
difference in case #2, apart from the fact that the first area of the outer
block is now also non-empty, as it contains a line-area with one space that
survives white-space-collapse. That area should not have an after-border, since
that should appear only on the last area (unless it is retained).
In case #1 white-space-preservation would also lead to the generation of a
second block area, without before-border.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.