You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Andreas L Delmelle <a_...@pandora.be> on 2007/09/16 22:50:20 UTC
Re: Expected Behaviour of Nested Break-before
On Aug 3, 2007, at 12:13, Chris Bowditch wrote:
> Vincent Hennebert wrote:
>
>> Hi,
>> I’m suddenly all confused about the supposedly expected behaviour
>> of breaks. Please have a look at the attached FO file and its PDF
>> result.
>> We get 2 pages. The break-before on the outer block and the inner
>> block are “merged” into just one... Why?
>
> Well I can't explain it from a spec point of view. However, the
> current behaviour is what the users would expect. In my mind there
> is no business scenario where a page would contain just the top
> border of a block and nothing more. And if there was such a use
> case then there are far more straight forward ways of reaching such
> an affect, namely:
>
> <fo:block border-top="solid 1pt black" break-after="page"> </
> fo:block>
Right. Another possible alternative is the slightly longer (I think,
haven't tried):
<fo:block border-top="solid 1pt black" break-after="page" white-space-
treatment="preserve"> </fo:block>
and this example, IMO, shows that the current behaviour is correct.
With default white-space- and linefeed-treatment, I would assume
there is no 'empty area' before the inner block's first area, so the
inner block is still leading on the second page.
Note that empty blocks by themselves, for example, also do not
generate empty lines. Putting a thousand empty fo:blocks in sequence
will accomplish exactly nothing. You need at least one preserved
white-space character to achieve a 'displacement' effect in block-
progression-direction.
If the breaks are also merged in case of preserved linefeeds and or
spaces, then FOP would be in error.
Cheers
Andreas
Re: Expected Behaviour of Nested Break-before
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi,
Andreas L Delmelle wrote:
> On Aug 3, 2007, at 12:13, Chris Bowditch wrote:
>
>> Vincent Hennebert wrote:
>>
>>> Hi,
>>> I’m suddenly all confused about the supposedly expected behaviour of
>>> breaks. Please have a look at the attached FO file and its PDF result.
>>> We get 2 pages. The break-before on the outer block and the inner
>>> block are “merged” into just one... Why?
>>
>> Well I can't explain it from a spec point of view. However, the
>> current behaviour is what the users would expect. In my mind there is
>> no business scenario where a page would contain just the top border of
>> a block and nothing more. And if there was such a use case then there
>> are far more straight forward ways of reaching such an affect, namely:
>>
>> <fo:block border-top="solid 1pt black"
>> break-after="page"> </fo:block>
>
> Right. Another possible alternative is the slightly longer (I think,
> haven't tried):
>
> <fo:block border-top="solid 1pt black" break-after="page"
> white-space-treatment="preserve"> </fo:block>
>
> and this example, IMO, shows that the current behaviour is correct.
> With default white-space- and linefeed-treatment, I would assume there
> is no 'empty area' before the inner block's first area, so the inner
> block is still leading on the second page.
That’s right. At the time I wrote that I was playing with border
conditionalities, and I made the confusion between leading area and
“begins the nearest ancestor reference area” that applies when
determining if a border shall be removed.
In this case the inner block is actually leading on the second page
since there is no sibling area preceding it. And I’ve just tested: when
adding white-space-treatment="preserve" on the outer block there are two
breaks like expected. So everything’s fine.
Thanks, and sorry for the noise.
Vincent