A way to prevent "orphan" Vertical or Text frames appearing at the bottom of a page
Suggestion: Add a "Keep with next system" option to Vertical and Text frames. Equally important however is some way to space the frame away from the top of the page: "Top gap" does not work at present.
Comments
Would be nice [cf. https://musescore.org/en/node/315338]
And an important reason to honor a "top gap" or have some other setting take care of this is the fact that default headers with page numbers will clash with a text frame like so:
In reply to Would be nice [cf. https:/… by worldwideweary
FWIW, the current default position of page numbers is a holdover from old releases kept for compatibility, but I'd recommend change it to move the page numbers into the margin if you use frames at the top of pages a lot.
Revisiting here because I just spent some time to disable a text or vertical frame from being the last on a page iff the next system after the frame along with it will not fit onto the current page, effectively making a "keep with next system" option for V/T boxes in the inspector.
Some opinions: Disagree with the statement "Equally important however is some way to space the frame away from the top of the page:" The contents of vertical frames can be given an increase of [top margin] already. Default [top gap] spacing is 7.0sp, and it only has effect when there's a previous system existing on the page. If layout were to use that 7.0sp without a previous system, all default positions of vertical frames originally at the top of the page would be offset by 7.0 from top page margin to the vertical frame. which would seem to be undesirable behavior. An option to honor the gap, regardless of being first on page, could work, but again, why not just use top margin?
Either way, it's nice to get this behavior of binding to the next system, because then it doesn't require a page-break beforehand, and that in turn means further changes of the score/layout wouldn't require a user to reapply another layout-break to make sure the text-frame is just above the next system.
Anyways, doesn't look like anyone considered this important enough to implement from 3.6 shutdown to now in 4.2ish
In reply to Revisiting here because I… by worldwideweary
Not sure what you mean about an increase of top margin. It's called "top gap" in 4.2.1, but it quite simply has no effect for a frame on the top of the page. There is no setting "top margin" setting, unless you mean the style setting, but that's global. The request here was a per-frame setting that can be used to space a frame below the top margin of the page. Such a control does not exist, but would be nice. Not sure that this is directly related to the orphan idea, though.
In reply to Not sure what you mean about… by Marc Sabatella
I meant exactly what is shown in version 3 here in this image:
![inspector.png]( "inspector.png")
Wasn't aware that this is no longer the case for Mu4 users. In 3.x, the [Top margin] field adds a margin to the frame's contents, but doesn't apply to images within that frame for some reason. Certainly a style to make use of top gap without a previous system existing on a page doesn't exist in 3.6.2 officially, nor apparently 4.2. I was mainly contesting the "equally as important"-ness of having that, since the ability to offset contents themselves would seem to serve the same intentions or get the same effect from my vantage point, but knowing that top margin in "properties" per frame is no longer available, maybe it makes more sense for version 4 especially.
Again:
And what the first thing topic pointed to is something like:
which I think is more important than having a top gap for top of paged vertical frames. Still, omitting priority, I can't think of any reason why there shouldn't be a "always honor top gap" option along with a binding to next system, or in other words, having no orphaned text/vertical boxes.
...Update: Just checked: looks like there is something similar to Top margin in the properties of Mu4: Top Padding. Seems to perform in the same way so far. Images should probably respect the padding settings of the frame though. ISTR an old conversation about this, but never got around to checking the code about it
In reply to Version 3: [inline… by worldwideweary
It's not the contents of the frame that are the issue - it's the position of the frame itself. Both MU3 and MU4 have controls over the contents already. The request was for the control over the position of the frame itself to also be controllable when at top of page. it's a valid request, although again, not specifically connected to the orphan control. But it does speak to why it doesn't get honored currently - because it would actually be a bad idea to have that top gap honored at the top of a page if it's just by chance that the frame is there at that top of the page as opposed to anywhere else with the page. Like, one might want the gap above the frame is there is other content there above, but not otherwise. That's the norm, in fact. But it's a valid request to want to be able to move the frame lower when it's specifically intended to be top of page (like if the previous page ends with a page break).
In reply to It's not the contents of the… by Marc Sabatella
Suppose I'm having a hard time understanding what in effect is different in a printable sense of a frame being positioned with an offset versus having its contents offset via margins, and in that sense, why I restate my previous main point, which is: that it is not of equal importance to allow a frame to honor top-gap when first of page as an option compared with an easy way to mitigate the orphan issue without resorting to manual page breaks, since the margin offsetting can give the same printable results already. Yet, as mentioned, I realize that images don't honor margins, which is another issue in and of itself... So in that sense, margins won't give the same "printable" results if a frame has image(s), which lends towards why it'd be a good idea to get them to be honored.
I think I'll add the "Always Honor Top Gap" option though for my personal build in addition, because it really is easy to do after already disallowing orphans: the frame merely gets positioned by the [minDistance] of previous system during page layout, but that doesn't exist for a new page. The minimum distance function provides the calculation of the top gap here:
![code.png]( "code.png")
That will need to be applied when prevSystem=null for a v/tbox when the option is also enabled
Summary:
+ Disallow orphaned text/vertical boxes option
+ Always Honor top gap option for text/vertical boxes to be applied when no previous system exists during page layout
+ Let images bound to a vertical frame (and horizontal?) have margins be calculated into their positionings. Not sure if Mu4 has that already or not, but my guess would be no.
In reply to Suppose I'm having a hard… by worldwideweary
Obviously if you only judge by the effect on the printed document, then gap and margin (combined with height) can be used to create the same effect. But that's not the point. margin is the right way to do some thing, gap is the right way to do others. Right now gap is ignored for frames at the top of a page, which is sometimes what you want, sometimes not. So a control over this would be nice, simple as that. Whether it's of "equal" importance as some other random feature for some given user depends entirely on that user's personal workflows. I could imagine users who would often use a "keep with next" and rarely use a top gap; others might be exactly the opposite.
In reply to Obviously if you only judge… by Marc Sabatella
P.S. One of the reasons to want a top-gap as first of a page would have been, in 3.6 and before, to fix the issue of collision with header text if it occurred, but this was fixed somewhere in 3.x during transitioning into 4.x. Jojo's hosted "3.7" for example has that taken care of (and Mu4).