> -----Original Message-----
> From: Peter B. West [mailto:[EMAIL PROTECTED]]
> Sent: August 14, 2002 11:24 PM
> 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. :-)


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to