pietsch,
(I've moved this part to fop-dev.)
I have just whiled away a few hours looking at this. In terms of what
it should do, the spec says, in 7.21.4 "leader-length"
<quote>
NOTE:
User agents may choose to use the value of "leader-length.optimum" to
determine where to break the line, then use the minimum and maximum
values during line justification.
Leader length values such as:
leader-length.minimum="0pt"
leader-length.optimum="12pt"
leader-length.maximum="100%"
would specify constraints that would cause the leader to fill all
available space within the current line area as part of the process of
justifying that line area.
NOTE:
... a leader formatting object's length-range provides further
flexibility to the justification process. Though any result that
satisfies the specified constraints would conform to this specification,
current typographic practice would tend to make use of leader length
flexibility in preference to other flexibility (e.g. word spaces) within
the same line area when justifying the line...
</quote>
As I read that, the maximum value does not come into play unless and
until the line is being justified, whether by virtue of a text-align or
a tex-align-last. The decision on how many fo:s fit on a line is taken
w.r.t. the optimum. The implication here is that there will generally
not be a great difference between the optimum and the actual value used.
However, if you are constructing a series of last-lines with, say,
text...page-number
the difference is irrelevant. It has already been determined that the
optimum fits on the line. The justification process then pads out the
line from the fo:leader, according to the Note from the spec., ignoring
word spaces.
If the code you quote is part of the line justification, it would be
ignoring minimum because the line breaking has already found that the
optimum will fit.
That still leaves some odd code, as you say. The relation
minimum <= optimum <= maximum
should always hold, and should be tested up front. If true, the code
above becomes
if (remainingWidth <= leaderLengthOptimum)
leaderLength = remainingWidth;
else if (remainingWidth > leaderLengthMaximum)
leaderLength = leaderLengthMaximum;
and the last condition (leaderLengthOptimum > leaderLengthMaximum) can
never be true. The author assumes, no doubt correctly, that the
min/opt/max relationship cannot be guaranteed from elsewhere. However,
that responsibility should be shifted into the basic compound handling
code, if only to simplify code like the above.
Peter
J.Pietschmann wrote:
> Thibodeaux, Paul wrote:
>
>> Correction - it doesn't throw in w fixed length, but it seems to use the
>> MAXIMUM rather than the OPTIMUM.
>>
>> I would have thought that it would respect the JUSTIFY and use OPTIMUM.
>>
>> Any good online explanation of how this works?
>
>
> How it works in FOP or how it should work?
> The implementation is in Linearea.java.
> Here is the code for computing the leader length:
> /**
> * checks whether leaderLenghtOptimum fits into rest of line;
> * should never overflow, as it has been checked already in BlockArea
> * first check: use remaining width if it smaller than optimum oder
> maximum
> */
> if ((remainingWidth <= leaderLengthOptimum)
> || (remainingWidth <= leaderLengthMaximum)) {
> leaderLength = remainingWidth;
> } else if ((remainingWidth > leaderLengthOptimum)
> && (remainingWidth > leaderLengthMaximum)) {
> leaderLength = leaderLengthMaximum;
> } else if ((leaderLengthOptimum > leaderLengthMaximum)
> && (leaderLengthOptimum < remainingWidth)) {
> leaderLength = leaderLengthOptimum;
> }
> The .minimum is not used at all.
> The code looks a bit odd, but I couldn't quite figure what
> it should look like. The wiggle room provided by leaders is
> not used for justifying the line (except for space leaders),
> only spaces are used.
--
Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
