On 18.06.2006 20:57:51 Simon Pepping wrote:
> On Sun, Jun 18, 2006 at 07:36:45PM +0800, Manuel Mall wrote:
> > I had a quick fiddle in one area and changed the Knuth penalty generated 
> > for a keep...="always" from INFINITE to INFINITE-1. In my few test 
> > cases that seem to have resolved the issue.
> > 
> > However, I am interested in comments of those more familiar with the 
> > mathematical background behind the Knuth algorithm if such a solution 
> > is appropriate or if there could be unintended side effects, e.g. this 
> > INFINITE-1 break being chosen even if there are other allowed breaks 
> > which should be preferred according to the FO input but have higher 
> > penalties when run through the Knuth algorithm.
> 
> Mathematically INFINITE-1 = INFINITE. Its having a different effect on
> FOP's layout decisions causes conceptual problems. I do not know the
> details of FOP's implementation of INFINITE. In my own implementation
> INFINITE gets special treatment. An effort to use values close to
> Integer.MAX_VALUE (which is my INFINITE) would lead to calculational
> overflow, simply because I do not expect them, and I think I have good
> reason to do so.

AFAIK, there IS special treatment of INFINITE in the existing breaking
algorithm. I don't think we're looking at the mathematical definitition
of INFINITE-1 here. INFINITE-1 is just the highest penalty which does not
prohibit a break. And that's pretty much what we need.

> > Or should we use a more refined approach were we generate initially an 
> > INFINITE penalty but if the page breaking cannot find a solution we 
> > reduce the penalty on some/all of those elements given an INFINITE 
> > penalty because of keeps and run the page breaker again?
> 
> I am in favor of this solution. There are generally two solutions:
> increase the tolerance, or force a solution. I think FOP already has a
> force parameter for this purpose.

+1. Yes, BreakingAlgorithm has a "force" parameter which is currently set
to true for page breaking. There's also a "threshold". We can probably
play with that first. See LineLayoutManager.findOptimalBreakPoints().


Jeremias Maerki

Reply via email to