DO NOT REPLY [Bug 28706] - [PATCH] More justification problems
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=28706. 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=28706 [PATCH] More justification problems --- Additional Comments From [EMAIL PROTECTED] 2004-05-20 08:25 --- Thanks for the link Simon. Although this patch may be redundant now with Luca's proposal on the way.
DO NOT REPLY [Bug 28706] - [PATCH] More justification problems
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=28706. 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=28706 [PATCH] More justification problems --- Additional Comments From [EMAIL PROTECTED] 2004-05-19 18:39 --- 1. See XSL-PR/slice7.html#suppress-at-line-break, whose default value is 'auto'. Block.handleWhiteSpace cannot handle this because it runs at the refinement stage. 2. This point is about code level. When you take a step back, you cannot see the point.
DO NOT REPLY [Bug 28706] - [PATCH] More justification problems
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=28706. 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=28706 [PATCH] More justification problems --- Additional Comments From [EMAIL PROTECTED] 2004-05-17 07:42 --- Hi Simon, thanks for your additional comments. On your first point regarding trailing spaces, just to be clear, are you saying there shouldnt be trailing spaces according to the XSL-FO specification, or is this your opinion? Either way, you may be right, I just want to understand this problem from a specification point of view. After all there is a lot of talk about whitespace handling in the spec, and my understanding was that this is all dealt with in Block.handleWhiteSpace and so any whitespace left after that is intentional by the user, and by preserving it FOP is conforming with the spec. On your second point, I'm afraid I still dont follow completely. You are analysing the problem from a code perspective and seeing a possible flaw in the logic. I understand that, and your reasoning looks good. However, I am taking a step back and saying I do not see the word spaces disappearing. Dont forget that patch 28314 is applied to CVS, so if that patch is the cause of the word disappearing I'm a little puzzled why it doesnt disappear when I run the test. If you have a different test case, then please attach it. Is anyone else observing this anomaly? Chris
DO NOT REPLY [Bug 28706] - [PATCH] More justification problems
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=28706.
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=28706
[PATCH] More justification problems
--- Additional Comments From [EMAIL PROTECTED] 2004-05-14 21:37 ---
Chris,
A trailing space at the end of the last line of a paragraph is
certainly a problem; it simply should not be there. While it does not
cause much harm, it is better to avoid it. It does point to a slight
problem in the logic of the code. The addition of the else branch
remedies that problem.
The word 'spaces' is there allright without the patch. The addition of
the else branch has nothing to do with it. The argument refers back to
patch 28314, where the word 'spaces' disappeared unless a change was
applied which added bp to vecInlineBreaks. I argue that I am not
completely happy with this change, and prefer to review the return
value of prevCouldEndLine, such that it returns false if prev is the
last item in vecInlineBreaks:
if (vecInlineBreaks.get(vecInlineBreaks.size() - 1) == prev) {
return false;
}
With this addition to prevCouldEndLine, instead of adding bp to
vecInlineBreaks, the disappearance of the word 'spaces' is avoided as
well.
Simon
DO NOT REPLY [Bug 28706] - [PATCH] More justification problems
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=28706. 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=28706 [PATCH] More justification problems --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 11:01 --- Hi Simon, I can see the trailing space in the second paragraph as you describe. However, both occurences of the word 'spaces' exists both in PDF output and the Area Tree. I am wondering if adding the else branch as you suggested to fix (1) actually causes issue (2). If this is the case, I may be inclined to reject this patch, because I'm not sure if (1) is genuinely a bug or not. I may be wrong here, as I am not up on all the details of the spec, but if you add spaces at the end of some text which is then dealt with by whitespace handling rules, in this case, multiple spaces collapsed into 1, then wouldnt you expect these to appear in the output? Perhaps the real bug here is the spaces collapsed in the third paragraph do not generate a single trailing space? Chris
DO NOT REPLY [Bug 28706] - [PATCH] More justification problems
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=28706. 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=28706 [PATCH] More justification problems --- Additional Comments From [EMAIL PROTECTED] 2004-04-30 08:16 --- Created an attachment (id=11392) Simon's patch
