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">&nbsp;</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

Reply via email to