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
