Hi Arved, Joerg, It seems you have a different view of how keeps work than what I was thinking. Section 4.8 of the spec seems to be the only real description, last paragraph.
In your example with blocks a, b and c. If you have a+b together and break after b this means that you have not satisfied a 5 keep but kept a 3 keep. The spec suggests this when talking about the maximal subsets of keeps. It says (ignoring breaks): - each keep must be satisfied - except where it would cause a stronger keep to fail - if breaking at equal strength then maximise satisfying these keeps (along with all strong keeps) - maximise subsets of stronger keeps On Thu, 2002-08-15 at 05:00, Arved Sandstrom wrote: > 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). This should be done like so: - continue to find best breaks in the first four blocks - the current best break will be before the second last line of the 4th block - for next break: block 5 has a keep prev so we cannot break after 4. - block 5 can break after 2nd line, this becomes new best break - page full so go back to last best break (2nd last line of block 4) So whatever you call it, it finds a future best break. Obviously if a block sees that it is going over the bpd it will return the next break regardless. For a brief description of the current idea (more ideas below to handle extra things). Each layout manager can find a break inside its own data/children. The flow manager gets best breaks until the last which is worst than the current best break. It could be worse because it is past the page end or further away from the optimal spacing or has a higher keep. So all the blocks have returned their best breaks, the flow has sorted these breaks out considering keeps, page bpd etc. The best break is then known for that page. The page manager then says to addAreas until the best break. Each child manager then adds the areas up to that break. This would mean that it only considers the keeps for the current page and not future pages. (another idea below) > 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. :-) Sounds like: - if the best break on a page has a keep (level 1) - more can fit on the page but with higher keep (level 2) - break at higher keep first then try next page to see if it satisfies a higher keep or more equal keeps (level 2) - continue to the end of all contiguous keeps - count up maximal subsets of all keep level satisfied - try again breaking at the original level 1 keep - compare subsets - use best result If there are more higher levels then repeat for each keep level. It has to find the breaks for all pages, count the keeps that are satisfied and the keeps that are not. Because the LayoutManagers find the break positions and compare breaks this could be possible to implement from what we have. The flow manager could handle this. I will maintain the following point: the layout managers concept allows us to explore how to do this sort of thing. Keiron. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
