>>>> 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
>> I attached my test file. On page three, the first line of Block U should be
>> on page four.
> 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
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
> 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. :-(
------ Kontakt ------
Geneon media solutions gmbh
Gutenstetter Straße 8a
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
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