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