Something is not right with both twsadjust and ipd settings under certain line breaking conditions. I'll attach a testcase showing the problem. I admit I am a bit out of my depth in this area of the code (Line LM - Line Breaking). If someone else please could have a look. The problems as I see them: 1. On the text area in the first fo:block the twsadjust value is set to "-897" resulting in the output being more "squished" than necessary. No other text areas in the example have a non zero twsadjust value. This also leads to different rendering of this line than the corresponding lines in the next two fo:blocks. 2. The second text areas in the second and third fo:block, that is the text areas for the string "and right border at the beginning of the and the end of the inline only. Any lines" are given an ipd bigger than the line area they belong to. While that is not visible in the output (PDF renderer) for the second fo:block on third block one can see it as the inlineparent also has been given an ipd wider than the line area.
Created attachment 16321 [details] Testcase xml file - no sensible checks yet
Created attachment 16322 [details] The area tree generated from the testcase
Re item 2: I think I know what's happening. There is a trailing space at the end of all the text areas that end at a linebreak. That space should not be there.
I'm going to have a closer look at what happens: in the testcase, areas should not have any adjustment, as the text is not justified. Your observation about trailing spaces is very interesting: I thought their removal was ok, but it seems there is something left to fix ... If blocks have text-align="justify" everything is ok; if it is "left", "right" or "center" it seems that the text is correctly placed, but the inline areas are somewhat larger than needed.
I just remembered what happens to the first block: it is not really a "bug" in the proper sense. The elements added at the end of a sequence in LineLM.Paragraph.endSequence() comprise (under some conditions) a glue whose width is > 0; its aim is for the line breaking algorithm to leave a little empty space at the end of the last line of a paragraph. This is not done when text-align-last="justify" or text-align="center"; maybe we should not do it even if text-align is "left" or "right", i.e. do it only with justified text, when its importance is bigger (as this helps reader to visually recognize where a paragraph ends)
It's funny to give new names to existing things and see the resulting confusion ... ;-) The "empty space at the end of the last line of a paragraph" is also known as "last-line-end-indent". I'm going to make the LineLM use the value of this property.
Now both items should be fixed (svn commits r279338 and r279551). Thanks for your detailed description of the problem, it really helped finding the errors in a short time!
Luca, I am reopening the bug because I found that item 2. (extra space at end of line) still seems to occur with hyphenation enabled. I'll attach a testcase file, the generated area tree, and the generated pdf (as it nicely visualises the problem). Please note that the fo:inline in the testcase is not required to reproduce the problem (it just allows highlighting the additional space in the PDF). You have to have a copy of fop-hyph.jar in the classpath. Just having hyphenate="true" is not enough to produce the problem.
Created attachment 16355 [details] Testcase xml file (version with hyphenate="true") - no sensible checks though
Created attachment 16356 [details] Area tree generated from attachment #16355 [details]
Created attachment 16357 [details] PDF generated from attachment #16355 [details]
Oops! I see the problem, and I know the reason: I fixed the method getNextKnuthElements() but forgot to fix getChangedKnuthElements() too ... Well, I think it's time for me to factor out some duplicated lines! :-)
The commit r280520 has removed duplicated lines in the methods getNextKnuthElements() and getChangedKnuthElements(), solving this bug definitively ... I hope! ;-) I'm leaving this issue "reopened", as I want to check the behaviour of other formatting objects which could have similar problems, especially fo:character.
Sorry Luca, I don't want to annoy you (really), but I think I found another problem (actually two problems). 1. Under text-align=right and hyphenation we are now 2780mpt (= one space) short. You got rid of the excessive spaces and now we are missing one :-). I'll attach a testcase for it. 2. If you uncomment the second block in the test (or make the first block text- align="center") you get a ClassCastException on a LeafNodePosition.
Created attachment 16392 [details] Testcase xml file You need to have OFFO fop-hyph.jar in the classpath for the problem to show.
Created attachment 16393 [details] PDF generated from attachment #16392 [details]
Well, it seems I was right (at least) in leaving this issue open! :-) Thanks for your quick feedback, I'm going to see what happens ...
please reverify this bug exists on the current FOP development trunk, updating the test input and resulting output files as needed
resetting P2 open bugs to P3 pending further review