Andreas L. Delmelle wrote:
That's one detail I was still unsure about. Only if the other factors remain identical, the algorithm would prefer a break at penalty 50 over one at penalty 100... but if the value of the penalty is only of marginal influence as you suggest, then this would indeed not be enough.
I made some quick computation to see how the demerits change according to the penalty value and the adjustment ratio (see the table in the attached pdf).
It seems that the penalty value is highly relevant as long as the adjustment ratio varies between -1 and 1 (i.e. we are choosing among breaks that are quite good), but rapidly becomes less and less important as the adjustment ratio grows.
For example, in order to let the algorithm prefer a break with ratio 2 (and no penalty value) to a different one with ratio 1.5, the penalty value for the second penalty should be at least 500; and no penalty value can make the algorithm prefer a break with ratio = 3 to another one with ratio = 2.5 (as we use 1000 as "infinite penalty").
In the example I posted earlier: <fo:block> Some text with "auto" keep-constraint <fo:inline keep-together.within-line="100"> Some text with a keep.within-line constraint of "100" <fo:inline keep-together.within-line="500"> keep.within-line="500" </fo:inline> Some more text in the first nested inline </fo:inline> More text after the first nested inline. </fo:block>The "acceptable" set of breaks may turn out to give a result like (with '|' = the end-boundary of the line)Some text with "auto" keep-constraint" |(1) Some text with a keep.within-line constraint of|(2) "100" keep.within-line="500" |(3) Some more text in the first nested inline |(4) More text after the first nested inline |(5)Only the third and the fourth line I'm still unsure about. May the content in the fourth line be broken itself?
I'm quite unsure about the third line too, as the outer keep constraint affects also the space between the inner inline and "Some more text ..." so break #3 is violating the keep and even creating a very short line.
I would probably expect something like Some text with "auto" keep-constraint" |(1) Some text with a keep.within-line constraint of|(2) "100" keep.within-line="500" Some more text in |(3) the first nested inline More text after the |(4) first nested inline |(5)where the inner keep with higher force is fully satisfied, and the outer one is violated twice (breaks #2 and #3).
But maybe the algorithm could still prefer Some text with "auto" keep-constraint" Some |(1) text with a keep.within-line constraint of |(2) "100" keep.within-line="500" Some more text in |(3) the first nested inline More text after the |(4) first nested inline |(5) where the outer keep is violated thrice (breaks #1, #2 and #3).So, maybe my sketched strategy would respect the keep priority (the inner keep will never be violated by a lower force one) but does not find the minimal set of violations. Or, at least, not if "minimal" means just fewer violations; if it could be interpreted as "fewer violations producing a good-looking result" it could be ok.
One last quick note concerning nesting: what if the inner inline had a *lower* force? feasible breaks in it should be first given a high penalty (to see if we can put everything together) and then a lower one (so the penalties should hold a nested chain of force values)?
This fuzzy logic is complicated! :-)
Luca
demerits.pdf
Description: Adobe PDF document
