Hi Vincent,
>>>> If the wide block is in the first column, the result looks like I 
>>>> expected it, but then I had a wide block in the second column and 
>>>> instead of moving to the next page, I got balancing again:
>>> I couldn't reproduce that. Can you please post the FO file showing the 
>>> issue?
>> I attached my test file. On page three, the first line of Block U should be 
>> on page four.

> Hmmm.
> The diagnostic is quite easy: the first column doesn't contain any elastic 
> space and doesn't exactly fill the page; so there's enough room for the 
> spanning block to squeeze in one line of content, instead of being deferred 
> to the next page. Set background-color="#F0F0F0" on the region-body to more 
> easily see what's happening.

I have no idea, how elastic space is defined, but I guess, orphan-widow-control 
would then take care of that problem? I'll have to check but I think, there's 
no case, where a wide block in a two-column layout should break after one line.

> (As a side note, I saw you put the fox-needs-balancing property on the 
> page-sequence element. I think you want to define it on the spanning block 
> instead.)

Yes, error in the test file. I thought, I'd put fox-needs-balancing in fo:flow 
with default true and in fo:block with default inherit. So the spanning blocks 
( which, I assume, are what I called wide blocks) don't necessarily have to 
know about the property in the fo-file but could as well overwrite the flow 
setting, if necessary. Which, by the way, works quite fine, now I just have to 
find, how the property is correctly transfered from Block of Flow to 
LayoutContainer.

> What eludes me in this particular case, though, is why the algorithm didn't 
> put an additional line of Qs at the bottom of the first column since there 
> is room for it.

Another think I just saw: On page two, the left column contains 41 lines, the 
right column one more and on page three, the first column has 43 lines. 

> Anyway, this suddenly makes the problem a lot more difficult, I'm afraid, 
> because it becomes necessary to do something on the layout side.
> I'm not too keen on it, I must say, since this whole area is likely to be 
> revised when introducing the new approach to line- and page-breaking.

> You can work around the problem by making sure that the columns will always 
> exactly fill the pages, i.e. by adding elastic spaces between paragraphs. 
> If your content is so made that at least one elastic space can be found on 
> every column, then you should never encounter the issue.

Except if the column is filled by one single block?

> Or it will occur rarely enough that you will be happy to manually fix it when 
> it does. 

No, manual fixing is bad, since I expect pdfs with up to 1000 pages. 

> Then it's still worth implementing the solution I proposed, but it will have 
> to be demoted from the status of official FOP extension to the less glossy 
> one of cheap unofficial hack. At any rate, I think it's your only hope to 
> have something working by the 5th of December... Then it's always possible to 
> discuss about a more definitive solution.

You know how it works. If I have a working hack by next Friday, I'll never find 
the time to make it a clean, official extension. :-(

Regards,
 
Georg Datterl
 
------ Kontakt ------
 
Georg Datterl
 
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
 
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert 

Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
 
www.geneon.de
 
Weitere Mitglieder der Willmy MediaGroup:
 
IRS Integrated Realization Services GmbH:    www.irs-nbg.de 
Willmy PrintMedia GmbH:                            www.willmy.de
Willmy Consult & Content GmbH:                 www.willmycc.de 

Reply via email to