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

Reply via email to