Music bottom margin is inconsistently interpreted and elements below the bottom staff of page can cross into page margin in some cases
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
In both 3.2.3 (Linux) and 3.6.2 (Windows), the music bottom margin setting is fully ignored. Here I am setting it to 2 sp, with the show margins feature enabled:
That’s visibly less than 2 sp…
Comments
(ignore the many parenthesēs, they are for experimental placement of things in the footer)
Incidentally, setting it to 8.5 sp gives me this: (3.2.3)
So it does place from something, just from where?
Measured with GIMP in a screenshot, at 500% MuseScore zoom, 1 sp = 37 px.
37 * 8.5 = 314.5
Now look at where 315 px up from the page bottom is… HUH‽
The user-level problem here is:
I want to keep lyrics bottom distance at 2 sp (because this is also used for the difference between system1 lyrics to top of system2). But I want the distance between the bottom of the score, whether with lyrics or without, a tad smaller, around 1 sp. I can only achieve that by letting the top of the footer reach a litte into the page inner area. But I also need to set the music bottom margin to get appropriate distance, and any value I set there that’s not completely ignored is way too high for the case when there are lyrics.
For me the music bottom margin is working as expected in 3.6.2 on Linux. It's the distance from the bottom of the "skyline" for the bottom staff to the line indicating the page margin. I think what you're seeing isn't an issue with the margin not being honored - it's the fact that the skyline is including the 2 sp lyrics margin also. Which was a convenient hack for spacing staves but probably there needs to be a separate calculation for dealing with the bottom margin, one that ignores that margin.
It does seem the behavior is different in MU4, but I haven't fully sorted out how.
In reply to For me the music bottom… by Marc Sabatella
It definitely does not work as expected in 3.6.2 on Windows: even with the 2 sp bottom margin, the note almost touches the page margin line.
Some more experimenting for 3.2.3 (I see only now that the screenshots from 3.2.3 above except for the last don’t include the green page margin line) show that the 8.5 sp I set in a score are the distance from the bottommost line on the bottommost stave to the green page margin line.
Or, expressed differently, the notes below the stave (half of G₂ (bass clef), entire F₂ and lower) are probably missing from the skyline (unfortunately, I don’t think I have the option to make the latter visible).
I’ll have to experiment with 3.6.2, too.
Could also be some other setting of your score getting in the way - if you attach it, we can take a look. But I just tested on Windows, and it works for me there too. Here is the default empty score with just the single note you see pictured in the first bar of the last system, and the music bottom margin set to 2.0 sp as shown:
![Screenshot_20221102_021837.png]( "Screenshot_20221102_021837.png")
Looks like what I expect - 2 sp space between the note and the margin.
Good point about attaching a test score. I reduced it a little but it does exhibit the issue, even more, I got it to actually touch the page bottom in 3.6.2 despite the 2 sp requested margin (padding in CSS terms).
Screenshot of RDP client, cropped to show.
I also reduced the footer to one line, so it doesn’t get into the way, even though (at the high level) I’m doing this to fit two-line centre footers.
4 sp is the smallest setting where I get any kind of effect. I’ve outlined 4 sp from the bottom of the note (which, previously, was touching the page border line) in GIMP, at 500% mu͒ zoom (33 px/sp):
Ahem. This is also just the distance of the bottom line of the stave to the page margin, ignoring the notes below.
So, to summarise:
In 3.2.3, if a note goes below, it can reach below the page bottom; the cutoff point is the lowest stave line:
Okay. Now I know this I can work with this, and I believe that, if I fix up scores with this in mind, they render the same in both versions (which is relevant for mu͒.com).
I think it's your "disable vertical justification of staves" setting that is mucking with the algorithm. Vertical justification is a "new" feature as of either 3.5 or 3.6, so older scores might have it turned off by default, and thus you'd still be seeing older behavior/bugs in terms of interpretation of the bottom margin. But set to the current default of enabling the justification, the setting seems honored correctly, which is why it worked for me in the default empty score.
Also, your spacer is likely also confusing things a little.
ad 1: probably, but that wouldn’t matter because I use a spacer to actively trigger shoving the bottom stave far down enough to exhibit the bug
ad 2: indeed, but that is specifically to trigger the bug (it also occurs in vertically tight notation, since that’s where I noticed it, but using the spacer I can push down the stave for as much as it allows me to, which makes making examples of bugs easier)
Since right now it seems the problem unique to scores with these attribute, I've updated the title.
It seems the algorithm is different in MuseScore 4, but I'm not sure if it' by design or not. The music bottom margin seems to ignore the skyline and instead set a distance from the bottom staff (while still also making sure to keep content below the staff from crossing into the margin). I think this is on purpose, and a good thing in that it means the bottom staff will generally be in the same position on all pages unless the content below the staff exceeds that margin. Whereas in MuseScore 3.6.2 it often ends being somewhat ragged.
Which part of “it also happens without, but I’m using the spacer to make the example easier to see” did you not understand?
Sorry, I wasn't able to reproduce the behavior of elements dipping into the page margin with the spacer (and only with fixed spacer), but I'm sure it's possible if precise steps to reproduce the problem from scratch are provided.
What does seem to be the case spacer or not is that the music bottom margin is measured from the staff itself, not the skyline. I am pretty sure that much is by design, even if it doesn't always get applied correctly.
Since it seems already fixed (or at least changed) in MU4, it seems kind of moot. But anyhow, I've updated the title again to hopefully summarize the situation without stating anything that isn't actually known to be true.