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=28314>. 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=28314 Alignment of the last line in a justified block Summary: Alignment of the last line in a justified block Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have tried to solve the problem of the last line in a justified block, which sometimes is justified too, instead of being left-aligned. This problem arises when the fo:block ends with spaces (the last TextLM's text ends with spaces), or with a LF followed by spaces (the last TLM's text contains only spaces), while if the block ends with a non-whitespace character it is handled right; the test fo file I'm going to attach shows these different situations. So, a possible solution could be avoiding these problematic situations to happen: as the end of a block always implies a line break (or not?) the ending spaces can be removed. This is what the proposed patch I'm going to attach does, slightly modifying the Block.handleWhiteSpace() method: - define another RecursiveCharIterator, called spaceIter, initialized null - inside the while loop, it is updated (if it's null) cloning charIter before nextChar() is called, and set to null again if the current character is not a space; so, if it is not null it points to the first element in a sequence of spaces - once the loop ends, if spaceIter is not null it is used to remove thr spaces at the end of the block Without any other code change, this seem to solve the problem. An alternative approach: why doesn't the LineLM change text alignment for the last line? Alignment is changed if (bTextAlignment == TextAlign.JUSTIFY && (prevBP.isForcedBreak() || isFinished())) { and in the problematic cases isFinished() returns "false", so text alignment is not changed. This is what happens during the LineLayoutManager.getNextBreakPoss(): BreakPoss a || BreakPoss b vv |.... end of text. | - inside the while loop, bp = curLM.getNextBreakPoss() returns the break possibility "a", which could be used to end the line, and is saved in prevBP - at the next iteration inside the while loop, bp = curLM.getNextBreakPoss() returns the break possibility "b", which is not good (bBreakOK == false) - the TLM has finished, so at the next iteration getChildLM() returns null, and the while loop ends - the LLM calls setFinished(), because there are no more child LM - now prevBP=a, bp=b, so prevBP != bp - oddly, prevCouldEndLine(prevBP) is false - so the reset() function is called, which calls AbstractLayoutManager.reset (Position), which has these lines: if (isFinished()) { setFinished(false); } (in the other problematic situation it's a different TLM which returns "b", but the LLM behaviour is quite the same) It seems to me that the value returned by prevCouldEndLine(prevBP) is wrong, but I didn't investigate any further as I was quite satisfied with the result obtained in the other way. Luca
