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)? 


Reply via email to