Accidentals no longer tuck under/over previous notes

• Mar 8, 2019 - 17:58
Reported version
P1 - High
S3 - Major
PR created

This is not a regression from 2.3.2 but it is a regression from where 3.0 was until shortly before release. This picture tells the story nicely:


There is no good reason for the space between before the accidental - it could be tucked under the previous note. It would have looked this way in 2.x, but this was actually one of the first major improvements implemented for 3.0 and was indeed one of the main reasons for moving to the "shape" system instead of the old spaceLw/space/Rw system of calculating segment distances.

Unfortunately, this broke when we added support for the old spaceLw/spaceRw in the form of addHorizontalSpacing(). This was needed in order to restore correct spacing for glissandi, and it also re-fixed the space allocation for ties. But now, we need to update the spaceLw/spaceRw calculations to not include the things that are already part of the chordrest shape. I'm on it. With any luck, this will be one of those fixes where simply removing some chunks of old code will make things work better.

See also


So close, but it's actually a bit more complicated, and I've run into a problem I don't see a good solution for. This was already a problem before…, which was when addHorizontalSpacing() was introduced, and I suspect this never actually worked.

But the approach I am taking is promising enough I went ahead and created a PR as a work in progress:

In the description, I discuss what works and what does not. Maybe someone else can see a solution that I don't.

So far I still don't see a totally automatic solution, but in the PR I propose a reasonable alternative: making it so disabling autoplace on an accidental (or dot, or other symbol attached to a note) will cause it to be ignored in the note spacing calculation. This will effectively allow it to tuck under other notes, and have the side benefit of making a quick workaround for the issue that accidentals can widen measures unnecessarily (if they would already have been stretched enough to not need additional space for the accidentals). It would be up to the user tnot to disable autoplace for accidentals that do need the space, though.