Hi Dario, Welcome!
By implementing a recovering mechanism you actually did something that I hadn’t planned to do before a while. I’ve always carefully crafted my examples so that I’d never run out of active layouts; the goal being to keep the prototype simple for now. I knew I’d have to look into this sooner or later. Eventually this recovery mechanism will not only be needed for best fit, but in general, whatever the choice of the layout method. I’ve had a look at your patch and I’d have a couple of questions/ comments: In LegalBreakHandler: - what is the purpose of the countLayoutClass variable? - mind the second part of the ‘if (ratio < -1.0 || p.isForcedBreak())’ test: are you sure your modifications inside this if branch are meant to apply to such a case? - why are you removing the last element from the layout? - the ‘removed’ boolean will be set to true as soon as one layout overflows its containing part (l.78). But that doesn’t mean that, inside the ‘if (best != null)’ branch, the best layout will be this overflowing layout, does it? What if there is another feasible layout that appears to have fewer demerits than the overflowing one? - plus, the demerits that will be computed for the overflowing layout will correspond to the overflowing part (line/page); not to that part after the last element has been removed. In that case the demerits may be completely different, possibly lower, or higher if the part becomes underfull. In ParagraphLayoutManager: - what do you mean by ‘paragraph best fit’ actually? - I didn’t get the purpose of the oldMinPageNum and newMinPageNum variables. I understand it’s to trigger the selection of the best-fitting page, but why does the fact that those variables become different mean that it’s time to proceed with the page selection? - why did you implement page best-fit in this class? What happens for a document solely made of blocks (or paragraphs of 1 line)? >From a higher level point of vue, my hope is to be able to do without any backtracking, that would cost much processing time and memory. I do realize that this pretty much kills your whole approach :-\ Basically the algorithm would remain the same; only, steps would be introduced at judicious places (!) where some layouts would be early discarded. For first fit, as soon as a part is completed all of the other layouts corresponding to the same part would be discarded. For best fit, you keep one layout per layout class: in a call to next(), you compare each completed layout with the current layout of the same class, and you keep the best of them. I suggest you not to bother about recovering right now, and make your examples such that a final layout will be found in any case. The recovering mechanism is a separate concern IMO (basically, the idea will be to keep an underfull layout under the hand, ‘just in case’). I hope the above helps. Don’t hesitate if you have any other comments/questions/suggestions. <snip/> > I've read you are working on table implementation for the prototype, I > was wondering what are the following steps, which features the prototype > needs before you can conclude the experiment as successful and start > porting the algorithm in fop trunk. Getting tables working would allow me to validate the approach I think, since it’s one of the most complex typesetting objects. The next step is then to validate the design: for example working on tables made me bring major architectural changes. Implementing a few other features like widows and orphans, keeps and breaks, maybe side-floats, would allow me to ensure the prototype has the right shape. The rationale being that heavy refactoring is much easier on a prototype of a few thousand lines, rather than on a software of hundreds of thousand of lines... Vincent