Manual positioning altered for certain element types on spatium change

• Apr 14, 2017 - 19:09
Reported version
S4 - Minor

Windows 10, GIT commit: de38cce

Discovered while working on #187151: Hairpins shifting out of position on systems containing ties from stem. Not a recent regression in general - this goes back to before release of 2.0. For hairpins in particular the problem was introduced a little later than the others, but it was definitely there by 2.0.3.

1) create a score with a time signature, a two-note quarter note chord with an arpeggio, and a hairpin
2) apply a user offset to the time signature, chord stem, arpeggio, and hairpin
3) change spatium value

Result: the user offset for those elements is altered. Basically, we aren't scaling them, because we override spatiumChanged() but don't call Element::spatiumChanged() (or whatever the parent is).


This also occurs for certain elements on a "local" spatium change - that is, altering the staff scaling in Staff Properties. Some elements will have their manual positions scaled correctly, others don't. For instance, elements attached to chords (like arpeggios, dots, accidentals) don't. Hairpins actually do, but the *default* position for hairpins on scaled staves is not calculated correctly it seems. That's another bug - on staff scaled to 200% add a hairpin starting with a downstem quarter note, and compare to the results on an unscaled staff. For the unscaled staff, the hairpin starts at the stem; for the scaled staff, it starts to the right.

My guess is that this same fix will be relevant in master, but I will check into that after 2.1 and I have my build system set up for master again.