FWIW, I completely agree with the realization that integer keep values
cannot be directly mapped to penalty values and that the breaking algorithm
may have to be called multiple times with different penalty values to
get the right results.

more inline...

On 20.07.2007 10:52:59 Luca Furini wrote:
> 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.

The spec does say "some maximal satisfiable subset of conditions of that
strength must be satisfied", so the algorithm should theoretically try
to minimize the number of violations. So it does put an emphasis on the
number of violations and not on the "beauty" of the result. But by
choosing good penalty values I would imagine that the algorithm would
still produce an satisfyable approximation.

> 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)?

My read of the spec is that lower force keeps will get overridden by
stronger keeps on parents.

> This fuzzy logic is complicated! :-)

Yeah.


Jeremias Maerki

Reply via email to