Hi Andreas, wow, I am impressed by your detective work...
On 2015-07-23 Andreas L. Delmelle wrote: > > On 2015-07-22 Jan Tosovsky wrote: > > > > 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. > Do you expect this difference should be further eliminated or your patch is ready for incorporating into trunk? >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)? Jan
