On Jul 19, 2007, at 10:49, Luca Furini wrote:
Hi Luca
Firstly, hi all! It has been quite a long time since I last posted
or committed anything, but I'm still here!. :-)
Then, congratulations for all the great progresses fop is making!
Good to see you're still monitoring. :-)
Andreas L. Delmelle wrote:
[inserting penalties with higher value to represent numeric keeps]
This should steer the line-breaking algorithm in the right
direction to satisfy all keep constraints, IIC. The only big
difference compared to an auto keep-constraint, if I judge
correctly, would then be that we would somehow have to use
penalties to represent all legal break-opportunities. Instead of
glues being considered as feasible breakpoints, they would always
be preceded by a zero-width penalty having a value corresponding
to the keep-constraint governing the base FO.
I'm not sure the "steering capability" of penalty values would be
enough to get the prescribed result [section 4.8 "Keeps and
breaks" (particularly the last paragraph)]: the algorithm could
still prefer violating a keep with force = N to satisfy some keeps
with force < N, as, IIRC, the demerits ultimately depends much more
on the necessary stretch / shrink than on the penalty value.
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 think that the breaking algorithm could be performed one time for
each distinct force value. Something like this:
lastConfirmedBreaks = ... the set of breaking points
considering only "always" keeps
ArrayList forceLevelList = findForceLevels(sequence); // in the
reversed order
int forceLevelIndex = 0;
boolean tryAgain = true;
while (tryAgain && forceLevelIndex <= forceLevelList.size() - 1) {
revisedSequence = setPenaltyValue(seq, lastConfirmedBreaks,
forceLevelList.get(i), HIGH_PENALTY_VALUE);
... compute the set of breaking points for revisedSequence
if (... they are still acceptable) {
lastConfirmedBreaks = ... these ones
i ++;
} else {
tryAgain = false
}
}
- in the sequence, keeps having force = "always" would be
represented by +INF penalties;
- keeps with numeric force start with a 0 penalty value;
Interesting, so the bottom-line would be:
- no explicit keep-constraint -> all remains as it is now
- explicit keep-constraints -> penalties are inserted at each
feasible break
-> "always" = +INF (immediately mark the feasible break as a non-
desirable one)
-> integer-keep = 0 (mark the feasible break, but do not set any
values yet)
- the method setPenaltyValue() sets those with the given force a
high value, and those with greater force (which have not been
chosen as breking points, this is why we must pass the computed
breaks too) are set to +INF so we are sure they would not be violated
If this approach is correct, the key point would be how to decide
whether or not the computed set of breaks is "still acceptable" ...
Well, it will ultimately take some tweaking, but I think your above
ideas are enough to get it working in basics. The only real tough one
will be: "How to express the satisfaction of the keep-constraints in
a formula?"
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)
Line 1: no problem
Line 2: the text is wider than the line, and the keep is not
absolute, so relax it
Line 3: the content of the second nested inline fits together on a
line with the rest of the text under the first inline
Line 4: The remaining text of the first nested inline cannot fit on
the third line entirely, so move it to the next
Line 5: no problem
Only the third and the fourth line I'm still unsure about. May the
content in the fourth line be broken itself?
Thanks for the input!
Cheers
Andreas
