On 04 Jun 2009, at 14:11, Simon Pepping wrote:

Hi Ben, Simon & Vincent,

<snip />

Indeed, it is a horrible hack with regard to the meaning of a
page-sequence. But it is an interesting solution to the problem of
influencing FOP's page breaking algorithm.

The very same thoughts over here. A really interesting showcase of what FOP can/should do, but I'd go about the implementation differently. Still a worthwhile overview of what needs to happen, albeit behind the scenes, without requiring the user to do anything special.

<snip />
B.T.W., why does the algorithm not stop at hard page breaks?

IIC from recent debug-sessions, it does. Well, it's not really the algorithm that stops... If the FlowLM signals a forced page-break, the current block-list is returned, page-breaks are computed and the areas are immediately added to the tree. After that, the PageBreaker resumes fetching the following block-lists. The breaks for the latter part are computed later by an entirely separate PageBreakingAlgorithm. In fact, this is one scenario where the line-breaking continues with a possibly different available i-p-d.

Span-changes are another example where FOP currently already processes part of the page-sequence with a different PageBreakingAlgorithm.

I seem to recall that in the past this happened for hard line breaks.

This is indeed not so. Hard line-breaks just trigger the end of the current Paragraph and start a new one (an empty one, if it only contains a preserved linefeed, to produce a blank line), but the main getNextKnuthElements() loop is not interrupted. The forced breaks do, however, help the algorithm. I once ran a test with a document containing one single fo:block with the pre-formatted text of an entire book. Without 'linefeed-treatment="preserve"', FOP needed at least 768MB to avoid running out of memory, because it had to recompute all the line-breaks. Preserving the linefeeds, I needed only 64MB (maybe even lower, but I don't think I tried that).



Reply via email to