Real cross-staff frames

[uliska]

No idea if that's reasonably possible, but it should be possible to get the coordinates of the neighboring staves, either within the current NN-group or the whole score.

[uliska]

I have run in a situation where this is not only an enhancement but could even be qualified as a bug.

This is done with the code from the usage example file.
I think it's clear why the right borders don't match: The frame gets its X-extent from the original horizontal bracket, and that is different for NoteColumns with different width, like here with the b notehead being to the right.

For the task at hand (I need it on a slide tomorrow) I worked around with shorten-pair, but that's ugly and unreliable, I think it could easily (and unnoticedly) break when the overall spacing changes.

So there should be a way to make cross-staff frames reliably possible. I have a few ideas how one could approach that but don't know whether any of them would work.

Hard-code the X-extent

It should be rather straightforward to provide a way to override the automatic retrieval of the X-extent from the horizontal bracket. This is surely the easiest way to ensure fitting borders, but it isn't really elegant.

Link frames

I have no idea whether this is possible at the time when the frames are calculated, but it would seem like an option to "link" a frame to another, presumably by an id property. In that case one would retrieve the (automatic) X-extent from both frames and adjust them to extend to the larger value on both sides, so the overall frame would grow (instead of shrink) to fit together.

Include arbitrary staves in a frame

Here too I have no idea whether it is possible at the appropriate point in the complilation process. But conceptually it would be ideal if a frame could have a property include-staff with a context name, similar to the alignAboveContext property that can be used for some things.
Here the system would have to get the relative Y coordinate of the target context, and the y-upper or y-lower would be calculated relatively to that.

@KlausBlum do you have any idea?

[KlausBlum]

Sorry, I don't have any idea. It sounds interesting that one frame "reads" the property of another, but I absolutely don't know how to do that.

I could only offer another ugly hack:
I would rather take the staff that needs the widest frame (eventually use shorten-pair) and set its Y-extent to cover the staff above or below.
At least, this would avoid the need of fitting two frames with different widths.

[uliska]

Well, that's what I suggested as the last - and actually the most "correct" - approach. I don't think this is a hack.

The question is if - in a stencil callback we can get the relative coordinates of another - named - staff to calculate the offset.

If that is possible there would be two properties denoting the upper and the lower staff to be included in the frame, with both defaulting to the "current" staff. So by default the frame would behave like it does currently, but it would be possible to create arbitrary frames around multiple contexts.

Note: Such other contexts might as well be Lyrics, Dynamics or FiguredBass (probably others too).