DO NOT REPLY [Bug 35940] 1.0dev differences to 0.20.5

2012-04-01 Thread bugzilla
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

2005-08-25 Thread bugzilla
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

2005-08-19 Thread bugzilla
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

2005-08-19 Thread bugzilla
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

2005-08-02 Thread bugzilla
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

2005-07-30 Thread bugzilla
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

2005-07-30 Thread bugzilla
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

2005-07-30 Thread bugzilla
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.