Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Should we encode system/page breaks in the semantic music? #275

Closed
clnoel opened this issue Dec 2, 2021 · 3 comments
Closed

Should we encode system/page breaks in the semantic music? #275

clnoel opened this issue Dec 2, 2021 · 3 comments

Comments

@clnoel
Copy link

clnoel commented Dec 2, 2021

@ahankinson said:

An alternate method of encoding 'pages' is to insert "milestone" page-begin (<pb />) elements to provide renderers with the ability to break the content as needed. This means that pages are not structural elements -- they do not 'contain' any musical data, and as such are not integral to the encoding -- while still providing page-rendering hints. These milestone elements do not have children (they're the functional equivalent to the <br /> in HTML).

This is the current approach taken by MEI and TEI. (There is also <sb /> for system-begin and <lb /> for text line-begin).

We use "begin" instead of "break" to mark the start of a new page, rather than the end. This is because sometimes you want content to flow between explicit breaks with no specific locations, but you do want to insert a specific break before the start of new content -- the beginning of a recapitulation, or an instrumentation change, or to avoid specifically awkward notation passages. In actuality there is no real difference -- a beginning of a new page is also an ending of the previous one.

That said, the MEI community has identified places where structural page elements are useful. We wrote a paper about this a few years ago. I think the specific implementation has moved on from that described in the paper, but the motivations are still valid.

Furthermore, Verovio can render according to the page-based layout if encoded, it can ignore the encoded page layout, or it can automatically impose a page layout for encodings that have none. You can see this behaviour on the Verovio editor*: Choosing the options under the 'View' menu shows how a score would be rendered as a document, or in a responsive layout.

It seems to me that if you have all these -layout elements, a page-layout element, outside of the musical element hierarchy, and perhaps in the <head> would make sense? Renderers could ignore or read the data as they like, and it would be optional for those scores that did not specify a page layout. This could contain the margins, footers, etc. Then <pb /> elements in the content (or their equivalent) for where you want to force a page break.

* The editor is currently a proof-of-concept, so don't think that this default layout is the best that it can look! The document layout shown isn't adjusted at all, so the page margins look really small. There are controls that could be adjusted to make this look better.

@joeberkovitz replied:

I think @ahankinson's suggestion of milestone-based system/page break elements is right on and probably even essential. It's common for authors to specify "must begin a new system at this measure", a flag which is honored on the fly when an application generates a run of pages. While I don't think we should spec this fully here (and I hope he will file an issue for it), it does underline the fact that pagination is often dynamic. So... MNX will need to be able to talk about page layouts even if there are no specific <page> elements (e.g. placement of page numbers, headers, footers, etc.).

So ultimately we may need a <page-layout> although I would propose grouping it along with system layouts under a new <layouts> container as this benefits the styling proposal - see #263 (comment) for an example of why this helps.

@clnoel suggested:

At first I was opposed to this idea. Most of the point of the layouts was to avoid putting this kind of information in the parts. However, upon reflection, I think I can support an optional break attribute on measure-global, with the following values:

  • never: Do not break here when making a new layout.
  • optional: (default) Breaks are allowed here.
  • recommended: Prefer to break here rather the next or previous measure when making a new layout.
  • required: Break here every time. If the current layout doesn't say to do so, form a new system horizontally aligned with the previous system.

never would probably only be used in pieces where measures do not align across parts, which is out of scope for V1. recommended would be used for logical break points like rehearsal marks, and required for the start of a coda.

(I just realized I never actually split this out from #266, and I don't want it to get lost!)
@joeberkovitz
Copy link
Contributor

Thanks for doing this @clnoel. a few things we can take up here:

  • One side effect of this issue is it may help us understand better what <page> is for in the common case where systems are flowed dynamically rather than taken from a rigid list of system breaks.
  • of course breaks are often different in different scores. Do semantic breaks function in all scores?
  • it might be nice to harmonize the names of the break options with CSS which already covers similar cases.

@adrianholovaty
Copy link
Contributor

Just adding my two cents that I agree MNX should support this concept.

@adrianholovaty
Copy link
Contributor

I think this is safe to close, given we've added the concept of scores, pages and layouts. Each layout can have its own page break data. This one's solved! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@joeberkovitz @adrianholovaty @clnoel