Lines misplaced on load if layout is different since last save
(Sorry, I am no longer familiar with the web site as I used to be and I could not find the issue tracker any longer! So this is a duplicate of https://musescore.org/en/node/276308 feel free to delete either one!)
Context: MuseScore version 2.3.1 from PPA and version 2.3.2 AppImage under Linux Mint 17.3.
Steps:
1. Create a score with version 2.3.1 containing some lines; a sample score is provided both with and without forced system breaks (it is the first page of a score of mine)
2. Read it with version 2.3.2
Result: If system breaks occur at different places (which DOES happen, rather unexpectedly for a minor version update), lines are misplaced.
Expected result: Lines keep their place regardless of other layout events.
Screen shots:
1) The sample score as loaded by version 2.3.1 (with which it has been created). Note the line under the top part in meas. 18 and its defined position (H -0.5sp and V 10.50sp, manually set):
2) The same score as loaded by version 2.3.2. Note that the line moved to meas. 11 and horizontal offset became -99.59sp. It can also be noted that several other lines changed of position: the one from meas. 31 moved to meas. 32, the one across meas. 32 - 33 is now split part above meas. 27 and part above meas. 33 (as now meas. 32 and 33 are across a system break).
3) The same score loaded by version 2.3.2, but with added system breaks to force the same flow. The lines keep their original places.
It seems as the lines attempt to remain in more or less the same absolute horizontal position (approx. relative to the page) even if the measures underneath move to other positions because of differences in laying out algorithms from one version to the other.
Of course, lines should keep the same position relative to the music they are attached to, regardless of other questions; the fact that the page layout changes from 2.3.1 to 2.3.2 is already annoying enough by itself...
| Attachment | Size |
|---|---|
| LineShift-2_3_1_nosysbreaks.mscz | 42.49 KB |
| LineShift-2_3_1_withsysbreaks.mscz | 42.49 KB |
Comments
Hi, and good to see you around here again!
These sorts of problems are unfortunately not new, there have been a number of related issues that have been fixed. This particular one is, I suspect, most related to #250381: Wandering hairpin in score with mmrest & invisible staves. Yes, the description seems different - no mmrests or invisible staves here - but that was in a way just the trigger. The real problem is that when we write the file, we write it with offsets relative to the current system, and if after a read and initial layout the systems change from how they were saved, those offsets are now incorrect.
You would indeed hope this change in layout between save and load - doesn't happen, but unfortunately sometimes it does. Sometimes it happens because of a change to the layout algorithm between versions, other times due to font changes on your system, other times because it was saved on one OS but loaded on another and metrics & calculations differ, other times just because subtle details of layout can depend on the exact order things happen in, and occasionally that means layout immediately after a load is different than what it is after lots of editing operations.
Anyhow, I took the liberty of changing the title to reflect what I am 90% sure is going on here (eg, it's not specifically related to version, but to any change in layout between save and load). I don't know if anything has changed for 3.0 regarding how we store lines, but this would be a good opportunity for someone to investigate and perhaps revisit this while there is a good opportunity.
It would also be interesting to learn what changed between 2.3.1 and 2.32 that resulted in a layout change - that seems very surprising to me. Still, as I said, layout shifts between save and load can happen for all sorts of reasons, so the fundamental issue here is really the inappropriate reliance on layout not changing.