DO NOT REPLY [Bug 35940] 1.0dev differences to 0.20.5
https://issues.apache.org/bugzilla/show_bug.cgi?id=35940 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #9 from Glenn Adams gl...@skynav.com 2012-04-01 06:43:18 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 14:20 --- Fixed, thanks for signalling this bug! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 14:08 --- I have finally found where the problem lies: 1) in the sample file there is a trailing space at the end of the centered text 2) the sequence of elements created for a space inside centered text is glue - penalty - glue - box - penalty - glue 3) the method LineLayoutManager.endSequence() removes penalty and glue elements at the end of the sequence, before adding the final elements; thus, the LineLM removes only the two last elements in the sub-sequence representing a space, leaving the other 4 elements and corrupting the resulting sequence So, the bug could be either in 1 (there should not be a trailing space) or 3 (elements removal should be more sophisticated), or maybe in both. As white space handling is not a code section I know very well, I'm going to fix the endSequence() method. :-) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 15:53 --- (In reply to comment #6) I have finally found where the problem lies: 1) in the sample file there is a trailing space at the end of the centered text ...because the linefeed after Result is converted into a space character, AFAICT. This is because of the default values for linefeed-treatment and whitespace-treatment (both handled inside fo.flow.Block.handleWhiteSpace() during refinement). 2) the sequence of elements created for a space inside centered text is glue - penalty - glue - box - penalty - glue 3) the method LineLayoutManager.endSequence() removes penalty and glue elements at the end of the sequence, before adding the final elements; thus, the LineLM removes only the two last elements in the sub-sequence representing a space, leaving the other 4 elements and corrupting the resulting sequence So, the bug could be either in 1 (there should not be a trailing space) No, I don't think so. I think this is white-space-collapse specified to kick in during area tree generation. or 3 (elements removal should be more sophisticated), or maybe in both. Only 3 IMO. As white space handling is not a code section I know very well, I'm going to fix the endSequence() method. :-) Not the reason I'd have chosen, but I think it's the right place to fix it. :-) I know white space handling pretty well by now and the linefeed that is converted to a space in this case seems to be correct. It seems like white- space-collapse is the thing that is not working properly. I've also found something else earlier about leading spaces when white-space cannot collapse. I haven't fixed that problem, yet, but it's another story anyway. At any rate, we need good test cases to check for all the combinations. But I don't know if the layout engine facility is good enough to check for all the details that come into play here. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 12:00 --- It seems that this happens, in particular, when the centered text is much shorter than the available width: for example, it is enough to add a 2cm start- and end-indent to the first block to have its text placed in a single line. Note that the 1.0 dev version creates *3* lines for that block: one with Victorian Land Index Property Address, the second with Search Result and a third empty (or so it seems) line. I think this could have something to do with the restarting mechanism in the breaking algorithm. I'll try and have a closer look at what happens during the line breaking of this block. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 17:45 --- Created an attachment (id=15826) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15826action=view) The sample FO file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 17:46 --- Created an attachment (id=15828) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15828action=view) The PDF as generated with 0.20.5 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 18:26 --- Initial analysis: (In reply to comment #0) Had a first go at using 1.0dev as replacement for 0.20.5 and noticed a few problems with my sample: 1. Everything seems to be rendered in Times Roman font although the specified font selection is Verdana, Arial, Helvetica, sans-serif As 0.20.5, the trunk code doesn't support the comma-separated font lists, yet. It doesn't even see the Helvetica or sans-serif entries. It falls back to the default which seems to have been changed to serif. 2. A line is broken when it doesn't needed to, i.e. the text Victorian Land Index Property Address Search Result is broken into two lines although there is plenty of space to have it on one line Interesting. Only seems to happen for text-align=center. It doesn't happen with start or justify. Need to investigate that more closely. 3. There is extra space between table rows, i.e. between the text mentioned above and the date/time line is an empty line in the pdf when it shouldn't be. Same problem. Problem is only present with text-align=center. I'll attached sample fo and pdfs. Note to self: Create a layout engine testcase for this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.