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