Hi Jan > On 23 Jul 2015, at 21:47, Jan Tosovsky <j.tosov...@email.cz> wrote: >
> > Do you expect this difference should be further eliminated or your patch is > ready for incorporating into trunk? At first glance, it looks like the change can be committed to trunk with little risk. That is: it does not break any existing tests, and would offer a solution for this new one. On the other hand, note that it does not (entirely) solve the original issue reported in FOP-1444, which seems to be more related to using fo:page-number-citation. > > From my (naive) point of view, wouldn't be possible - during processing > whitespace - somehow process that fixed width box (if breakOpportunity is > false) in same way like in the second case (glue)? Possibly, but not sure if it would be worth the time and effort to investigate that right now. Purely from the perspective of the layout algorithm, one can expect different input to lead to a difference in output. In the first case, there is only one stretchable piece of content in the line, namely the fo:leader. The space behaves like a NBSP here, which is never stretched. In the second, there are two, which leads to the total stretch/shrink for the line being distributed over those two, which is where that ~1400mpt (about 0.5mm) comes from. I keep staring at both lines, and wonder whether either one looks 'better' than the other, but I cannot decide... :) That said, before one even notices said difference, at least two conditions need to be satisfied: 1° the content of the two lines (blocks) is similar enough (read: almost identical) 2° one block should be using keep-together, while the other does not Even under those two conditions, the lines also need to be close enough together. If either one of the lines appeared at the top of a page, and the other in the middle or at the bottom, I doubt I would even have noticed it in the rendered PDF in the first place. KR Andreas
