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
