Andreas L Delmelle wrote:
> On Aug 3, 2007, at 12:13, Chris Bowditch wrote:
>> Vincent Hennebert wrote:
>>> 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.