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

Reply via email to