DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29124>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29124

New line breaking algorithm

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From [EMAIL PROTECTED]  2004-09-05 18:21 -------
Luca,

Patch applied. Thanks for this innovative and extensive contribution.

Still to be done:

- Resolve the regressions mentioned above.
- I support the idea to create an InlineLayoutManager interface, which
  extends LayoutManager.
- This patch has made a lot of existing code redundant. Much of that
  code is still present. To keep the code clean and intelligible, the
  redundant pieces should be removed at some time by somebody.

I have added a space after casts. See the style guidelines in the file
dev/conventions.html of the FOP web site.

I have a few remarks about the code. I leave it to you to follow these
up or not, but I would like to see point 1 addressed:

1. In TextLM:
// linefeed; this can happen when linefeed-treatment="preserve"
// the linefeed character is the first one in textArray,
// so we can just return a list with a penalty item

In LineLM:
if (returnedList.size() > 1
    || !(thisElement.isPenalty() && ((KnuthPenalty)thisElement).getP() ==
-KnuthElement.INFINITE)) {
} else {
    // a list with a single penalty item whose value is -inf
    // represents a preserved linefeed, wich forces a line break

Can we be sure that U+A is always alone or the first item in a
textArray; does this not depend on the Parser, how it calls the SAX
characters method?

2. In InlineStackingLM.applyChanges: Falling over the end of
oldListIterator can be done better: treat only currLM != prevLM in the
loop, treat !oldListIterator.hasNext() after the loop. Same for
getChangedKnuthElements? :

while(oldListIterator.hasNext()) {
    oldElement = (KnuthElement)oldListIterator.next();
    currLM = oldElement.getLayoutManager();
    // initialize prevLM
    if (prevLM == null) {
        prevLM = currLM;
    }

    if (currLM != prevLM) {
        bSomethingChanged = prevLM.applyChanges(oldList.subList(fromIndex,
oldListIterator.previousIndex()))
                            || bSomethingChanged;
        prevLM = currLM;
        fromIndex = oldListIterator.previousIndex();
    }
}
bSomethingChanged = currLM.applyChanges(oldList.subList(fromIndex, oldList.size()))
                    || bSomethingChanged;

Possible cases, after the loop:
xxyy or yy, xx done
prevLM = currLM = y
fromIndex = last done (2 and 0)

3. In InlineStackingLM: Unnecessary differences between treatment of
returnedList and returnList in getNextKnuthElements and
getChangedKnuthElements. In getChangedKnuthElements it is not
necessary to have a separate returnedList and returnList.

4. Break up long methods in LineLM: findHyphenationPoints,
getNextBreakPoss, considerLegalBreak (?), findBreakingPoints (?).

Regards, Simon

Reply via email to