DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
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=27773. 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=27773 [PATCH] Hyphenation --- Additional Comments From [EMAIL PROTECTED] 2004-04-09 09:28 --- Hi Luca, Your patch looks good. It works fine on your test fo, and it also works fine on a test fo I had lying around. There are a few things to note: AreaInfo.bHyphenated is identical to (flags BreakPoss.HYPHENATED); ai.ipdArea = MinOptMax.add(ai.ipdArea, new MinOptMax(hyphIPD)) is equivalent to bp.setStackingSize(MinOptMax.add(ipd, new MinOptMax(hyphIPD))). In other words, the same information is present in the BreakPoss, which is held by the LineLM. Unfortunately, this information is not accessible in the addAreas method of TextLM. This is so because posIter.next() returns the position member of the BreakPoss, not the BreakPoss itself. I believe that is an error in PositionIterator which eventually needs correction. For now your solution is a good one. Your proposed TextInfo.hypChar is also known as LineLM.hyphProps.hyphenationChar. This information is not passed on to childLMs and thus not known to TextLM. Storing it in TextInfo seems a good idea; perhaps it is not even needed in hyphProps. It is not completely clear that +if (ai.bHyphenated) { +str += foText.textInfo.hyphChar; +ai.ipdArea = MinOptMax.add(ai.ipdArea, new MinOptMax(hyphIPD)); +} is always correct. This happens on the last AI returned by posIter.next(), which is not necessarily the last one in the line. But it is hard to conceive of an AI which is last in its LM and also hyphenated; therefore it will work. Ideally, the LineLM indicates which BP is the one ending the line; perhaps this needs correction at some time. Regards, Simon
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
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=28237. 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=28237 [PATCH] Use the commons logging LogFactory also in Fop.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-09 10:09 --- Glen, (a) why place within isDebugEnabled() and isWarnEnabled() conditionals, why does this matter? To be as reticent as possible. If a user uses -d but his configuration also sets the log level to debug, he already has what he wants; skip the command line option silently. Similarly with -q. (b) one conditional is !isDebugEnabled() with a negative but the other is the positive isWarnEnabled()--was this a bug? -d and !isDebugEnabled() means that the user does not yet have debug log level but requests it, so we have to do something. -q and isWarnEnabled() means that the user still has warning level or a more verbose level on but requests quiet mode (error level), so we have to do something. (c) Finally, did you actually mean isErrorEnabled() for the latter? No, isErrorEnabled() means error level enabled and perhaps more verbose. We need to ensure that we are not more verbose than error level, that is, !isWarnEnabled(). For the dumpConfiguration method of CommandLineOptions, if the user requests -x but does not set debug log level, he sees no configuration dump. That does not serve the user well. My patch checked that and used a debug enabled SimpleLog in that case. Alternatively, it might be a good idea to show the configuration at info log level; after all, this is information that the user explicitly requested. Regards, Simon
DO NOT REPLY [Bug 28314] New: - Alignment of the last line in a justified block
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
DO NOT REPLY [Bug 28314] - Alignment of the last line in a justified block
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 --- Additional Comments From [EMAIL PROTECTED] 2004-04-09 15:08 --- Created an attachment (id=11199) test fo file
DO NOT REPLY [Bug 28314] - Alignment of the last line in a justified block
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 --- Additional Comments From [EMAIL PROTECTED] 2004-04-09 15:08 --- Created an attachment (id=11200) proposed patch