fix #58796: layout of one line staff

[MarcSabatella]

See discussion in usse thread. The bbox for a one-line staff is currently set to be 2sp high, but it goes from 0sp above the staff to 2sp below. Meaning that elements like brackets and staff names that position themselves according to the bbox are off-center vertically - they are 1sp too low. The staff spacing is also off by 1sp for the same reason. There is code to reduce the staff spacing for one-line staves by 1sp, presumably in to account for that padding, but since the padding is all below the staff, the space abvove is incorrect.

My proposed change here makes it so the bbox for the SysStaff for a one-line staff extends 1sp above & below the staff, rather than 0sp above and 2sp below. Unfortunately, SysStaff has no way to determine the number of staff lines for the staff it represents - it contains a staff index but no pointer to the score. I elected to preserve that, so I instead added a "yOff" member that records the vertical offset of the staff within the bbox. This is initialzied to 0.0, but for one-line staves it is set to 1sp at the same point where we calculate the bbox for the SysStaff.

Code works in my test cases, but I don't know if there are places where we really rely on the position of the staff being the same as the position of the bbox.

[MarcSabatella]

Staff spacing is still not quite right. Not sure what the right answer is: should the extra padding aroudn the staff be considered part of the staff for spacing purposes? That is, should the staff distance control the distance to the staff itself, or to the bbox? I'm inclined to go with the latter. After all, clef, time signature, and barlines extend above / below the staff line as well.

[MarcSabatella]

Udated to work as proposed. For purposes of determining staff spacing, a one-line staff is treated as if it extends 1sp above & below (so, spacing is the same as for a 3-line staff).

[MarcSabatella]

BTW, you'll only see that effect for scores with a one-line staff at the top or bottom of the score. Otherwise, the initial barline just goes all the way through. Meaning, "shooting through the bracket" is actually the norm, although usually it shoots through by more than a few pixels. Anyhow, I'm not sure it's really worth doing anything differently at all.

[MarcSabatella]

Examples from published literature would be nice. As it is, I hate to give up the 2sp above/below barlines, but I also don't want to see brakcets unnecessarily big. One thing worth mentioning - for staves that are bracketed, they often have barlines that are also extended through the whole group, and if the top staff of the group is a one-line percussion staff, often they don't exten 2sp above (similar,y the bottom staff often doesn't extend 2sp below). So I'm not seeing many cases where this comes up in the published literature I am seeing.

[lasconic]

This is a great improvement. However we still have a problem with the default height of markings (crescendo, dynamics etc...) below 1 line staves. Maybe the yOff could be used in this case.

@wschweer any comment on the implementation?

[MarcSabatella]

We could try calculating staff height and adjusting offsets accordingly for staves that are not 4sp. This would also help with tab staves that are taller than usual. But this seems not really the right solution. We should have a way to set the distance below staff directly, and I think it should come in conjunction with a way of flipping elements above / below the staff.

BTW, I did look at quite a few published examples to see how they handled the initial barline, and found lots of different solutions. The trick of not extending the barline above/below a one-line staff if it is the first/last of a span was probably most common. We could implement that easily enough, but note it only works if the bracket span matches the barline span. Or we could increase the span of the bracket slightly it if starts or ends with a one-line staff. To me, that's not important to decide & solve right away, though.

[wschweer]

merged manually