Re: horizontal spacing regression

[Keith OHara]

On Fri, 14 Jan 2011 03:20:15 -0800, Joe Neeman <address@hidden> wrote:

> I think you'll find that the regression was caused by ee0488,

Yes. Reverting the commit to fix 1120, from current master :
+ restores the spacing with accidentals, so 1474 goes away
+ maintains the same tucking as master, in spacing-horizontal-skyline.ly
+ restores the multi-measure rest spacing, so 1472 goes away
+ and for some reason correctly spaces notes with melismata, so 1120 remains 
fixed
+ gives a make check with just small spacing shifts,
and un-tucks a dis in { e'''8 <dis'' gis''>8 r2.} which was not the point of 
the regtest.

> in which case
> the extra-spacing-height override is exactly the thing to do if you want to
> restore the old behaviour. It's really just a question of how much padding
> to add;

I was not able to achieve the happy combination above with padding.

The attached music helps me see the big picture.  There are a lot of issues in 
these two measures; note that the collisions with stems are due to their being 
cross-staff.  The 'tucking' aspects are seen in the {ces16 fes} left of the 
single bar (want un-tucked) and the {b,!16 gis} just left of the double bar, 
where the gis moves right of the dot below if I add any significant 
extra-spacing-height to Accidental.

-Keith

reversion.diff
Description: Binary data

C.revert.png
Description: PNG image

C.master.png
Description: PNG image

C.stable.png
Description: PNG image