Hi Jan

> On 22 Jul 2015, at 23:32, Jan Tosovsky <j.tosov...@email.cz> wrote:
> <snip />
> I've removed whitespace between all inlines (spaces seem to influence this
> behaviour significantly) and I can confirm that 'keep*' property has some
> influence here.

Indeed, good catch! I also looked a bit closer on my end, and it does seem to 
start with a very minor difference in the content lists for both scenarios.

The only difference is in the element generated for the space in between the 
two words. Incidentally, if you remove that one space, the output for the two 
blocks is identical. Vice versa, if you increase the number of words/spaces, 
then the differences get worse and worse...

In the case with keep-together, a space is represented by an auxiliary, 
fixed-width box. This automatically prevents a break from occurring before it, 
assuming that the preceding element is also a box.

Without the keep-together, a space becomes a stretchable glue, which does 
permit a legal break if it is preceded by a box.

The issue seems to be related to the fact that the generated glyph mapping for 
that space *always* gets an areaIPD that is a MinOptMax with different minimum, 
optimum and maximum values. That indicates the resulting area will be both 
stretchable and shrinkable.
In case there is no keep-together, this will correlate to the effective 
stretchability of the inserted glue. 
In case a keep-together is specified, however, the generated box is 
fixed-width, so the variance implied by the glyph mapping's areaIPD should not 
be applied.

To verify this, I tried forcing the areaIPD in TextLM.processWhitespace to a 
MinOptMax that does not allow for any stretch or shrink, only for the case 
where the passed breakOpportunity is false.
This corrects the alignment, and the only difference after doing that is that 
in the second block, the space is slightly stretched when compared to the 
first. Before the change, both spaces were equally wide, but for the first 
line, that means slightly stretched in comparison to the actual box's width.



Reply via email to