Last system of page is one staff height too far from margin

• Feb 22, 2019 - 22:20
Reported version
3.0
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

While working on #281253: Staff spacer down doesn't work at page bottom, I discovered another bug in the code handling the spacing at the bottom of the page: the last staff sits too high above the margin page. Using the default untitled score and setting the "Music box bottom margin" to 0 and then enabling "View / Show Page Margins" illustrates the problem well. The south skyline for the staff should sit directly on the page margin - that is, the lowest thing below the staff should just touch the margin. But it doesn't, there is an additional 4sp gap. That's the height of the staff, which is being counted twice in the calculation of the amount of space left on the page. That's because the height of the bottom staff is actually included in System::minBottom().

Probably it needs to be fixed within System::minBottom(), but I need to be sure there is nowhere else that this is actually being depended on. There's an equally good chance the same problem in the code leads to other problems, like too many or too few systems being selected to fit on a page.

Comments

• Feb 22, 2019 - 22:54

Sure, enough, I found two other problems directly related to this. As I surmised, we are sometimes failing to fit an additional system on the page because of the wasted 4sp. Also, vertical frames are getting an additional staff height (4sp) gap between them and the staff above them even when "Vertical frame top margin" and "Top gap" are both set to 0. Same reason for all of these, minBottom() should not be counting the staff height. So, the same fix applies to all of these issues.

Debug / Show System Bounding Rectangles also relies on this, but in this case the code was partially designed around this, so it gave correct results at least some of the time. Fixing this to work with the new minBottom() (and then work in all cases) requires a corresponding change to scoreview.cpp.

BTW, I'm leaving these notes in case I don't fully work this out and need to turn it over to someone else, but I think I'm reaching the end of the tunnel.

Reply

• Feb 24, 2019 - 15:27

That makes sense, but music top margin behavior would have to be adjusted accordingly then. Currently, if you set it to 0, it'll put the top line of the top system at the margin, and all the music bleeds into the page area (which I love very much and would like to replicate on the bottom!). The reason I like this behavior is that it allows me to have equal distance from the top/bottom line of the top/bottom system to the actual page edge, which ensures all systems across all pages are at the exact same vertical positions.

Here are some screenshots from my previous thread:
https://musescore.org/sites/musescore.org/files/2019-01/botmarg.png
https://musescore.org/sites/musescore.org/files/2019-01/topmarg.png

Reply

• Feb 24, 2019 - 15:52

My same PR fixes the bug in the top margin that allows the note in your image to erroneouy extend into the margin (and indeed right off the page if it goes high enough). See #284637: Elements above top system can cross into margin and off page

So if you like music in your margins, the correct solution is to not use page margin bit instead use music margin. This works already if you set them correctly, except the bottom margin currently needs to be set 4sp less what you actually want due to this bug.

Reply

• Feb 24, 2019 - 16:24

I hadn't thought of just using very large top/bottom music margins, and doing away with page margins completely. Sounds like a nice idea, so thank you!

Reply