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
