This patch fixes the problem with leading spaces after a line-break. Such spaces should be suppressed according to J.Pietschmann: http://marc.theaimsgroup.com/?l=fop-dev&m=107185453129923&w=2
Created attachment 9687 [details] The patch against HEAD
Created attachment 9688 [details] A test .fo that illustrate the problem.
I think the new boolean first is equivalent to vecInlineBreaks.isEmpty(), so that the patch could be: inlineLC.setFlags(LayoutContext.SUPPRESS_LEADING_SPACE, (vecInlineBreaks.size() == iPrevLineEnd - && !vecInlineBreaks.isEmpty() && ((BreakPoss) vecInlineBreaks.get(vecInlineBreaks.size() - 1)). isForcedBreak() == false));
Simon, your patch is certainly too simple. When vecInlineBreaks happens to be empty, then we are not allowed to access the vecInlineBreaks()-1 'th element. So there have to be at least a check for that.
We need code comments, also a more descriptive variable name so people understand X months from now what it is for--what does the boolean "first" variable refer to -- first line? Thanks, Glen
Finn, I can add the comments in, but, apologies for my slowness here--what does "first" precisely indicate within the processing of the document? First line after a preceding line-break or block or what? Thanks, Glen
The use of 'first' is to indicate that space suppression should only happen at the very first flow object in a block. But Simon and Glen's comments have made me realize that that is probably wrong. Space suppression should occur for each flow object until a bp is added. So the test vecInlineBreaks.size() == iPrevLineEnd is enough and the badly named 'first' vrbl can be removed. Unfortunately this triggers a different bug where setting space suppression on a InlineStackingLM cause space suppression to occurs for each of the LM's children. I'll take a look at that problem, and until I come up with something, this patch should be suspended.
A new patch, that doesn't introduce new vrbls but uses the existing test for a new line. The patch also ensure that a child InlineStackingLM always uses the parent LM value for SUPPRESS_LEADING_SPACES. As it were, the parent value was only used when the InlineStackingLM started a new area. This patch also fixes bug 25743. Thank you Simon and Glen for your help. regards, finn
Created attachment 9696 [details] A new unified patch against HEAD that overrides the previous patch.
Created attachment 9697 [details] A slightly diffrent test that also checks for the bug in 25743.
Problem fixed long ago by knuth algo, patch no longer valid anyway.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed