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" 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 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. I'll attached sample fo and pdfs.
Created attachment 15826 [details] The sample FO file
Created attachment 15827 [details] The PDF as generated with 1.0dev
Created attachment 15828 [details] The PDF as generated with 0.20.5
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.
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.
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. :-)
(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.
Fixed, thanks for signalling this bug!
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed