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