Score layout shifts when saved etc.
Reported version
3.3
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MS 3.3.3 / Linux Mint / Win 10.
Open the attached score. Originally it looked like this:
But after saving some score elements have shifted (the line, and fingering above grace notes):
Making any change to the score restores the original state, but it will shift again when saved and reopened.
Similar issues: #289946: Layout shift after load in score with fingering; and #292614: Note beam height changes when other parts of the score are adjusted?
| Attachment | Size |
|---|---|
| line_shift_bug.mscz | 10.01 KB |
Fix version
3.5.0
Comments
Workaround is to make small adjustments to the vertical position of String Number and Fingering. Probably a corner case.
This issue is very similar to #297501: Layout shift of slur after reload and I will have a look into this one too.
Hmm, here it seems to be the "2" on the first grace note that is incorrectly laid out on load. My initial guess is that the fix you applied to the other issue won't apply here, that was more about making sure other things respond to the fingering correctly. This is about making sure the fingering itself is laid out correctly.
In this case, I think it is the slash on the grace note creating the problem - the fingering on initial layout is not responding to it. Turn on display of bounding boxes in the Debug menu and you can see it encroaching. So probably the slash is not being added to the chord or segment shape, or isn't being laid out soon enough.
That's exactly what I did and how I cam to the same conclusion. If you use a simplified example, just the note with the 2 grace notes, no fingering lines or whatever, then you see the slash is not contributing to the skyline but, seen at the logging I added, it is there. This was the easy part, now I'm doing a similar analyses as in #297501: Layout shift of slur after reload to figure out where exactly it goes wrong. I'm wearing my Sherlock Holmes cap and pipe again :-).
While this issue and Note beam height changes when other parts of the score are adjusted in how it appears to the user, the root cause is completely different.
You mean #292614: Note beam height changes when other parts of the score are adjusted I guess ;-)
See https://github.com/musescore/MuseScore/pull/5822
In reply to You mean #292614: Note beam… by Jojo-Schmitz
Yes. For some reason sometimes I can't get the right reference in the comment :-(
Notated as [#292614] (but this only works for issues, not for forum topics)
Fixed in branch master, commit 2498950a2c
_Fix #297482 - Score layout shifts when saved with fingering on acciaccatura
Solves the shift of the fingering on the grace note, and therefor the shift of the line above the fingering.
The root cause was StemSlash. Shapes for the StemSlash are created during the layout of the
beams of the grace notes and the layout of these beams is with the layout of the complete Chord
to which the grace notes belong. As a result, the shapes of StemSlash are added to the skyline
after the layout of the Fingering so the layout of the Fingering was based of the layout of the
Stem only.
After a re-layout the StemSlash is included in the skyline so the re-layout will move
the Fingering and, in this case, also the line.
The solution was a extra layout of the StemSlash in Score::layoutChords3() so it StemSlash is
included in the skyline in time.
Although this issue is vert similar as #302316 and fix #297501, the root cause is
different._
Fixed in branch master, commit 72ef2a5722
_Merge pull request #5822 from njvdberg/issue-297482-layout-shifts
Fix #297482 - Score layout shifts when saved with fingering on acciaccatura_
Automatically closed -- issue fixed for 2 weeks with no activity.