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. > 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. Simon -- Simon Pepping home page: http://www.leverkruid.eu
