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 

> 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 
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 
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.



Reply via email to