Bracket and instrument name misaligned to one-line staff

I assum you mean, you create a score with a one-line staff and a five-line staff, then add a bracket, and the bracket is misaligned in the same way as the barline? If so, then this too appears fixed with #51721: Staff miscentered vertically when set to 1 line musescore 2.0, and can close this. If you mean something else, please post a sample score and precise steps to reproduce the problem.

Hmm, I take it back, it is still misaligned.

Please post precise steps to reproduce.

P.533 of "Behind bars" at "Margin Brackets" : " A single-player timpani part (i.e. a single-stave part) or a single stave (or single-line) part for percussion does not require a margin bracket, since there are no other staves to join together."

Yes, agree with that (but the sigh was not necessary...)

Most probably because we now keep the top line rather then the middle line, when reducing the number of lines per staff

Sorry if I feel rude or annoying with my "please post precise steps" but it's really needed. Sometimes I read the bug report several times, and it takes me 15 minutes to manage to reproduce the bug while with precise steps anyone can reproduce in 30s. It makes the difference between a bug being fixed in a minor release or not...

I was looking at this, and see basically where the problem is, but am not so sure of the right solution.

The layout of the bracket is done here:

https://github.com/musescore/MuseScore/blob/f1b0364106c8a0e7b1ce06cdf09…

So it's really just set according to the bbox for the SysStaff. The bbox is set a little eariler:

https://github.com/musescore/MuseScore/blob/f1b0364106c8a0e7b1ce06cdf09…

staff->height() is literally the height of the staff for normal staves, but is explicitly set to 2sp for 1-line staves - otherwise they'd have zero height. The code here seems to be trying to account for that 2sp of height, maybe attempting to set the bbox so that the one staff line will be centered in it (the adjustment to "dup" for one-line staves), but that never actually happens. When it comes time to draw the staff, it is drawn to the top of the bbox. That is why the bracket is too low, and presumably why the staff name is as well.

There is another effect of this code - the staff distance is not interpreted the same way it is for other staves. I think this is probably a bug too, unless it's deliberately for some reason. But set "Staff distance" to 1sp in Style / General, and you'll see a 1-line staves will actually *overlap* the staff above, rather than being drawn 1sp below. Again, it seems if the staff line were actually drawn centered within the bbox, this would work.

So I think the solution might be to leave this code alone, but change the definition of SysStaff::y() to special case 1-line staves and add the 1sp offset. Or, we could change the layout of brackets and instrument names, to special-case 1-line staves rather than rely on the bbox (and fix the staff spacing calculation above).

Right, the question is which of the two solutions I mentioned makes more sense given the actual design of the code. It's more a question for Werner or lasconic :-). Either solution would produce the same effect for the end user.

That's not a bad characterization, actually, although not *quite* right. So I'll explain a little further - thinking aloud helps me clarify my thoughts, gives others a opportuntiy to weigh in, and maybe you'll find it interesting :-)

The "bbox" (short for "bounding box" is an imaginary rectangle that could be drawn around each object in a score (and in fact *is* drawn when running with the "-d" option). It normally just barely surrounds the object with no margin. So really, a one line staff *should* have a bbox with essentially zero height - well, the height of the staff line only.

But the bbox is used, among other things, to help MuseScore decide what object you are clicking or dropping a dragged item to. So there needed to be some extra space around a one-line staff or you couldn't drag a bracket to a one-line staff. It was to fix exactly this bug that the code I highlighted above was added.

That's what makes me say, having the bbox extend 1sp above & below the staff *does* seem to make sense. That's option #1 - centering the one staff line in its bbox. I like this because you probably *want* a drop zone both above and below the one staff line. And the bbox itself is already being set exactly as it should be for this to work - we'd just change the position of the staff line - and everything else - within that bbox.

But for most items, the bbox really is as tight as it can be. And for staves in particular, the top staff line is normally right at the top of the bbox. Who knows how many places in the code there are assumptions to this effect that would be broken if we allowed a one-line staff to *not* be at the top of its bbox. I won't be at all surprised to find some other bug caused by making that change.

The second option will produce *exactly* the same results on screen and in print. You would not be able to tell the different by looking - I'd adjust things so the staff is at exactly the same position, as are the brackets and staff names. There is much less chance this solution would break anything else. The staff line would continue to be right at the top of the bbox; it would continue to extend 2sp below. But I'd fix the positioning of the bbox so this places the staff line at the right place, and fix the placement of the brackets and staff names to match. It *is* a bit like addressing the symptom, but it has the advantage of preserving a possibly important property of bboxes - that the top of the object is at the top of the bbox.

It's really a philosophical question regarding the meaning of bbox, and whether it is OK for the bbox to extend above the object being bounded. To me, the *right* solution is actually to have two different bboxes - a tight one that accurately describes the dimensions of the object, and a "click zone" version that might default to the being the same but could be larger for one-line staves or other objects where it is seen as advantageous.

https://github.com/musescore/MuseScore/pull/2013

FWIW, the code above implements option #1, which turned out to be somewhat more compelx to implement because the way the code is structured, we don't actually knwo the number of lines in a staff at the moment we would need do to the centering of the one-line staff within the bbox. My change here allows this to work anyhow, but again I can't vouch for whether this works all the time. It does in my test case though:

Actually, staff was still slightly off in the above image - inconsistent space above versus below one-line staves. I noticed it just after posting, and had already posted an update to the PR. There is a subjective element to this, as one needs to consider the fact that barlines, time signatures, and other elements may also extend above/below the staff. Here is how the spacing looks in the current version of the PR:

If you focus on the staff lines, you will see there is 1sp more space above & below a one-line staff than a standard staff. But if you focus on on barlines, it actually looks like less space, because the barlines extend 2sp above & below a one-line staff. This to me was the msot pleasing compromise.

No change - addressing that still requires a new feature where there is a way to specify a distance *below* the staff for elements intended to be placed below. A way of having separate above / below staff settings is one of the possibilities for 2.1, and if that happens, that would fix #51061: Single line staff is spaced as if five lines.

But FWIW, the handling of text *above* the staff is one of the concerns I had with changing the bbox handling. As it stands, height of text is calculated relative to the top staff line, not relative to the top of the bbox. So a text style with a vertical offset of 0.0 sits directly on the top staff line. This is current and remains true for one-line staves. It's a bit odd, in that this means the text sits below the top of the barlines. There's probably no perfect solution. It confirms to me that at some point, we really need staff-specific style settings.

Fixed in branch master, commit f86fcb3e98

fix #58796: layout of one line staff

Fixed in branch 2.0.2, commit c1b5d099b9

fix #58796: layout of one line staff

Automatically closed -- issue fixed for 2 weeks with no activity.