On 04 Jun 2009, at 14:11, Simon Pepping wrote:
Hi Ben, Simon & Vincent,
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
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).