Unnecessary extra horizontal space added when adding accidentals or dots

• May 20, 2019 - 21:53
Reported version
3.0
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project

Adding an accidental or dot to a note increases the horizontal spacing between ALL the notes of the given measure. Horizontal space is added even if there was enough space to begin with to accommodate the accidental/dot. Other added elements might also trigger this issue, but I haven't noticed this with anything other than accidentals and dots yet. This tends to create uneven spacing throughout a score and ultimately detracts from the quality of engraving.

A workaround is adjusting layout stretch, but this is very cumbersome.

This might be related to the issue of accidentals not tucking under/over preceding notes.
#285591: Accidentals no longer tuck under/over previous notes

The attached file contains a several examples of this issue.

Attachment Size
Horizontal_spacing_issues.mscz 23.82 KB

Comments

Priority P2 - Medium

The issues are kind of related indeed. I've thought about how it might be possible to deal with this but come up empty. The way things work is we figure out the minimum space need for each note, and hence for each measure, and use that information to divide up whatever extra space after deciding how many measures can fit. What we would really need to do is have two different sets of values, one for the amount of space each note would need if it didn't have accidentals or dots, and then the amount it actually needs. When assigning the extra space, we'd decide how much space each note should get based on the value without accidental or dot, but then only actually give it the amount the exceeds the the difference between the two values.

And the difference between those values is related to the idea of accidentals tucking under - right now, we include that in the overall width of the note unconditionally (as if we were enclosing the notes in a box that wide), but really we should consider it to be just another component of its shape (so it only sticks out where it needs to). As I mention in my notes to that issue and the accompanying PR, this is actually easy and works well - except that unfortunately we don't at that time have the information we need on the stem direction and length of the previous note, so we can't really be sure if it will tuck or not. Still, if we managed two different shapes - one with the accidental & dot, one without - then we would have access to the different widths. Being able to include or exclude the fingering and articulation shapes would also be useful for various reasons.

So anyhow, I see this as doable but would require some fairly major surgery.

Meanwhile, a possible partial fix would be to allow unchecking autoplace on the accidental and dot to exclude it from the shape completely. This would allow it to tuck and also to not require extra space. Then you could uncheck it in the places where you can see that you can get away with it. Still a little bit of work, but less so than adjsuting stretch, and it's a simple switch rather than needing to eyeball just how much stretch. In my PR for the tucking issue, I included code to include it as a shape component but not to determine the total width, but what we'd need here is something different - to ignore it completely.

Even though it's not ideal, it does at least provide an easier way to get the desired result than the current method.

In reply to by Marc Sabatella

Thank you for the prompt reply, Marc. The possible partial fix you describe would indeed be welcome as an interim solution until the issue is fixed.

I understand why this will not be a quick fix. But it will definitely be worth the wait, because getting the spacing algorithm right will be a huge jump forward towards getting out-of-the-box good quality engraving.