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!

And finally, concerning the keeps ...

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.

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;

- 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" ...

Hope this helps ...

    Luca


Reply via email to