On Thu, Jun 04, 2009 at 11:35:17AM +0100, Vincent Hennebert wrote: > It is likely to interest other users who run into similar memory issues, > and the good thing of having made it against the 0.95 release is that it > won???t be made obsolete by further changes in the code. > > We are not going to apply this patch to the Trunk, though. This is > a workaround that, although quite clever, distorts too much the > semantics of the fo:page-sequence element. A page sequence really is > a self-contained set of typographical material, that should start and > end on its own pages (the common analogy is the chapter of a book).
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. Effectively, it inserts points where it guides the algorithm to restrict its optimization to the region up to that point. As long as we do not have a fundamental solution to the problem, causing OOM situations for users, this is a prototype for a nice interim solution: some hint that tells the page-breaking algorithm to stop here, calculate and ship the pages, and then resume. B.T.W., why does the algorithm not stop at hard page breaks? I seem to recall that in the past this happened for hard line breaks. It may have been me who undid that, in my work on block elements in line elements. I may have done that mostly because it seemed an unnecessary complication at that time. In the context of the current problem it may be good to revisit that. A hard page break is a much better hint than a pseudo-page-sequence. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
