> -----Original Message----- > From: Peter B. West [mailto:[EMAIL PROTECTED]] > Sent: August 14, 2002 11:24 PM > To: [EMAIL PROTECTED] > Subject: Re: FOP memory usage > > Joerg, Keiron, et al, > > This is why I have harped on the theme of lookahead. The layout design > simply must accommodate it, and must be able to preserve as much > information as possible from the initial layout attempts to minimise the > work of subsequent attempts. I have, as I have said before, made some > initial notes on aspects of this. It is why I believe that a something > like a layout tree is needed as the bridge between FO and area trees. > > I don't pretend to have any actual design worked out, but the broad > outlines of a solution to this have to be worked out first.
I don't see how some form of lookahead can be avoided. Let's assume that blocks 1-4 can be laid out on page 1, and we do so. Block 5 has a keep-with-previous; to satisfy that block 4 should be on page 2 (assuming that none of block 5 fits on page 1, and none of block 4 originally is laid out into page 2). My current belief is that lookahead is primarily motivated by keeps. Other things like floats or footnotes can be handled without this, and so can forward references like page citations if we allocate fixed space for a page number, to be filled in later. As Keiron said. Keeps, especially near-pathological combinations, I don't see how one can avoid lookahead. I don't view this as entailing any backtracking, per se; it's more a galley model. Once a page is cut or committed then it doesn't get revisited. Whole point is that we have a sliding window, in the presence of keeps, of partially laid-out stuff. RenderX XEP (I believe) has a configurable lookahead size...IOW, one might say that we will only do lookahead for 2 pages, or 4 pages. It's this lookahead limit that makes the problem deterministic, which it has to be in order for it to be coded. What are we expecting to do otherwise - handwave, and sort of expect the keeps problem to solve itself at implementation time? :-) There needs to be an algorithm, pseudocode or otherwise, that clearly explains how layout will occur in the presence of keeps. If there is something I am missing here I would dearly love to hear about it. :-) Regards, Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]