> <snip>/ >> Unfortunately, the original reporter did not take the time to reduce >> the example to a 'minimal' one. >> ... >> which makes it more difficult to pinpoint the cause. >> > > I am willing to reduce it a bit, but all next week I won't have an access to > my PC.
No worries, I already got that covered. :) Same basic structure, only two fo:inlines instead of one, where the first has a keep-with-next specified and the second a keep-together. The intention seems to be to allow for multi-line entries, see 1.1.13, 1.1.14 and 1.1.17 in the sample attached to FOP-1444. I think the same issue responsible for the glitch is also triggering the line break in entry 1.1.13 too soon. Not entirely certain, but it seems like the word 'here' followed by two spaces, a leader and a digit would actually still fit in the line (?) BTW, I also spoke too soon about FOP-1162, which still has one single entry in the TOC that exhibits the same glitch with a very similar content length range. Same structure, so seems to be the same issue. Replacing the fo:page-number-citations with literal numbers demonstrates that it is definitely related to the use of those. That introduces an additional stretchable piece of content, where the real optimum width is not known at the point where the line breaks have to be determined. If the TOC were placed at the end of the document in its own page-sequence, the problem would go away, as all the effective page numbers are known at that point. > I remember there is another justification issue, even with a patch: > https://issues.apache.org/jira/browse/FOP-2438 > > But I suppose there is no nbsp character in the original test case so it has > to be something else. Hmm... Seems like that is indeed indirectly related, and could be the basis for an alternative solution. Looking at the patch, it does seem rather drastic to remove the condition altogether and always use stretchable glues. In plain start/end aligned context, it is overhead to generate a sequence of three elements instead of one. I'll look into whether extending that condition to cover the text-align-last case is feasible. > Just a note, comparing both FOP-1444-original.pdf and > FOP-1444-original_after.pdf in separate browser tabs (and 'animating' the > difference by activating them) I can see changes in the right edge position > of all the page numbers except 'glitches'. Like they would be untouched by > your code... Correct. I noticed that as well... I did expect that, since before my change, the glyph mapping used for the space area had a larger max ipd than the element as seen by the line-breaking algorithm. I just assumed that previously those lines were actually overflowing, all by the same amount. To say for certain, I would have to check in more detail if the result for all but the glitched lines is 100% correct, i.e. the area ipd values should add up exactly to the available ipd for the line area. KR Andreas
