Add multi-line text area for copyright in New Score Wizard and File -> Score Properties

• Jan 23, 2013 - 03:43
Reported version
3.0
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Status
active
Regression
No
Workaround
Yes
Project

In current versions of MuseScore it is not possible to create a copyright notice that spans multiple lines from within the New Score Wizard.

In published music copyright lines are frequently 2-4 lines of text.

For comparison see the equivalent screens in Finale and Sibelius (attached).


Comments

"In the current nightly build however it is not possible at all."

Sure there is. Go to Style/General/Header, press the "..." beside the appropriate box and enter it all there.

However, any text styles applied are lost.

He was talking about a multi-line copyright, so this method of entry is valid.

Regardless, many aspects of the copyright (footer) area in MS 2.0 are lacking. A multi-line copyright created by whatever means can still easily be overrun by the bottom system. Adding a frame or a spacer doesn't work well to protect the area. So the whole copyright (footer) area needs similar protection to how the header is handled right now, via a frame.

No, the request is to have this possible via the new score wizard. What you describe is, at best, a workaround, and one that is inferior to the 1.x workaround. And I don't think the header is protected by a frame, like the title is, maybe you confused the two?

How do you manually enter a multi-line copyright in the New Score Wizard in 1.3?

I don't think that the way I described is a "workaround" considering the text editing capabilities it has. It would seem to be the more robust way to work with larger more complex copyright texts.

And, yes, I was confusing the "title" frame with the header. Just underscores the point that _both_ header and footer, especially when they contain something that can be overlapping with the score, need some form of protection to prevent that.

The wizard in 1.3 couldn't do it either. Hence this here is a feature request, else it would be a regression bug :-)
But once having used the workaround in 1.3, it goes into the meta tag, this can't be achieved in 2.0

But Jojo, how do you do this in 1.3?

I'm all for a multi-line input, but it won't achieve the editing detail that is needed. You will still need to be able to change fonts, edit the text to add bold, italic etc, possibly even add graphics. And right now, you can't do this on the score, nor in the Style/General/Header box if the data is defined in the $copyright variable.

Sounds like an entire re-think is needed on how header and footer data is entered and edited.

Perhaps the way forward here would be to include a tag mechanism for including things like copyright information in an ordinary text frame.

There are several of these defined in the header/footer system. If we made these available in text frames then production of a multiline copyright frame on the title page would be much easier.

The practice of including copyright info on every page seems to be waning in favour of a single message on the title page, so providing access to metatags in ordinary text frames would seem to be the way forward.

I think I like Finale's approach (judging by the image).

My scores have featured multi-line entries for title, subtitle and composer, so if we have copyright, I'd like it extended to the others (including lyricist).

Other than establishing these and centring the alignment of the text (the latter maybe possible as a default setting), I don't tend to make other adjustments and suspect there will be others who similarly don't. My opinion is that the essential information will be input and in many cases, won't need adjustment, but can be made later if required (e.g. fonts).

Adding protection for the header and footer is important, perhaps more important to implement than any copyright editor for now.

I'm not quite following the "protection" thing. If the concern is that the bottom system can run into the footer area, isn't that just a matter of making sure we pick good values for the bottom page margin and music lower margin in general / page style settings?

Marc, does this mean you want MS to change those values for you as the header/footer contents change, or make the user adjust those? I think either option is bad and wish for something better. Try to set up a single-page copyright, multi-line, where _only_ one page has the copyright displayed, and no other page has any margin adjusted.

Presently, MS only allows you to adjust the page margins for all odd or even, but not just one page. As an example, if I only want the copyright to exist on one page (e.g. the first, which is quite common), if I adjust the bottom page margin then those margins will change for all odd or even pages. However, if MS automatically took the height of the footer into account for the pages where it applies, then I don't need to worry or make any manual adjustments. And I can right now tell MS to only display the copyright on the first page.

An even better solution would be a "bottom frame", just like the title frame of the first page, but it would stick to the bottom margin. You could adjust it to the height you want, regardless of the contents, and MS would take the height into account. This would also allow you to drop in a graphic for a copyright instead of typing it in through MS and have the same protection.

So you're talking about special handling for the first page of the score, then? That wasn't clear. Yes, I can see the need for some sort of special handling there. From what I know of frame implementation, it might non-trivial to implement a special frame anchored to the bottom of the page - frames normally are a part of the measure flow and occur at a specific measure of the piece. But I'd bet a separate "first page margin" section of the page layout dialog would be relatively simple.

No, I'm not being specific to the first page even though copyright info contained in the footer is generally now only on the first page. Footer handling in particular in MS is far too complex; too many options, variables, several places to enter data, and margin or other page adjustments that only apply to even/odd pages. Copyright data specifically, and footer info in general, should be applicable to any page or pages where it needs to be. Hence the ability to add a bottom-only frame and protect any area that needs some footer info.

OK, but *currently* the first page is the only one allowed to have a unique footer, right?

As I said, I have a feeling the bottom-only frame idea will be DOA. But if you have a use case where it really is necessary to have a unique footer for page 7 only (for example), then perhaps at some point it could be accommodated. Do you have an example of such a use case?

I could see something simialr but a little different: "footnotes" like some editions of major classical works have. The footnote appears at the bottom of the page, but it is "logically" anchored to a specific measure - the measure it explains. So for this purpose, you wouldn't want an option to set the footer for page 7 specifically, but rather, to add a footnote to measure 129, and it would appear on the bottom of whatever page 129 happens to fall on.

No, headers and footers can apply to odd and/or even pages, or page 1 specifically. Yes, having a unique solution only for page 1 would work, but would be limited, regardless of a use case. A generic solution would still be the best and most flexible.

Here's a general use case for non-page 1 copyright, _and_ non-page 1 starting page number: any octavo-type choral work, booklet style. Typically you've got a cover, inside cover, and then a starting page, either starting at a 2 or 3. Presently, there's no way to set _only_ the copyright on the third page, and page numbering starting on the third page.

Footnotes would be somewhat different, as I see those in choral quite often, esp when songs are medleys and require a small copyright notice, either anchored to the measure where the song starts or a "*" at that measure and note at the bottom of the page (but not in the normal footer area).

About this:

"Presently, there's no way to set _only_ the copyright on the third page, and page numbering starting on the third page."

If we could select by click the page numbers or the footer (like we can with MuseScore 1.3), we could use the shortcut "v" to toggle visibility on a per-page basis. For example, with a 3 pages score, we could set invisible the copyright notice on pages 1 and 2, so it would be visible only on the third page. It's something that can be done with MuseScore 1.3.

Here's another, really easy possibility: separate fields for separate lines of copyright text. Maybe the New Score Wizard is still best with a single line, but if somebody wants to change it later, there could be separate meta tags for "copyright line 1" and "copyright line 2", the option (obviously) to add further tags, and a system to parse them for Style -> General… -> "Header, Footer, Numbers".

This is the way mailing addresses are often handled.

Title Add multi-line text area for copyright in New Score Wizard Add multi-line text area for copyright in New Score Wizard and File -> Info

Sorry to step in only to say something which is probably trivial, but word processors have approached the same issue since long and have worked out a working way to solve most of these points: page style.

Musescore already has the internal concept of Page and already spits out <Page> tags in the file contents, all of them empty.

Word processors (or, worse, typesetting software) might be very sophisticated with page styles, but MuseScore does not need to start with all the possible page style bells and whistles.

For instance, a page style cold include settings just for:

  • Margins
  • Header on/off
  • Contents of each of the fields of the header (L / C / R)
  • Footer on/off
  • Contents of each of the fields of the footer (L / C / R)

and most of the points addressed above would be solved or solvable.

The impact on the existing code base would be limited, I believe, as all (or most of) the current page/header/footer machinery could be left in place as "default page style" (whose existence would be built-in).

The UI would require:

  • a Page Style dlg box along the same lines of the current Text Style dlg box
  • a way to select a page (click on the footer / header?)
  • an Inspector widget for selecting the page style of the selected page

Not trivial, I agree, but nothing astronomical or greatly outside current MuseScore architecture.

A point to keep in mind could be: what to do if the the contents of pages change? The usual answers adopted by word processors is to keep the page style as it is. If the user thinks it no longer suits the page contents he can always update the page style of the 'special' pages (the majority of the pages usually being simply in the "default style").

Is that necessary? The principal use case remains that of the copyright notice. Simply adding fields for optional second or third lines to the New Score wizard and File -> Info (with support for this in header/footer syntax) would basically make it work automatically, with minimal changes to code or UI.

Like this mockup (I'm aware the content is absurd):
Screen Shot 3.png

@ZackTheCardshark #24: "Is that necessary? The principal use case remains that of the copyright notice.": it is true that the original request was 'simply' about multi-line copyright statement, but the discussion had shown that this is likely to involve other aspects as well: choice of page(s) to put the copyright notice into, variable height of the area remaining available for music and so on.

Not to mention that other fields may suggest similar requests, like for instance plate number (which rather surprisingly is not among the default info fields).

Thus, I suspect that we may start to accommodate 'simple' requests like this one piece by piece now with the probability to have to re-think the whole system later, when a number of details has been fulfilled with ad-hoc implementations.

A page style frame now (or soonish) would provide a framework for most (hopefully all) details to fit into.

Use a Unix style "\n" for linefeed, at least as a short-term solution? Or perhaps the HTML/XML equivalents? <br> or &#10; or &#13;

In reply to by schepers

I want to thank you for that comment, i was feeling kina annoyed cause i had just put some random letters down for the copy right and then i couldn't change it! Now i can!

(This is a bit lengthy, but please bear with me — I hope that this can clarify a couple of concepts relating to copyright notices and detail a framework that addresses most of the concerns I see in the conversation thus far.)

I think we’re confusing two things: the copyright notice and the associated legal statements. A copyright notice looks like this:

"©2019 by Ima Composer"

Associated legal statements are what cause these things to run into two, three, or even four lines. Examples include:

“All rights reserved.”
“Released under CC-BY-NC 4.0.”
“Published by Facetious Music, a subsidiary of Conglomerate Publishing, under license from Tiny Holding Company.”

These statements are details — important details, mind you; even legally necessary, at least in some cases — that don’t belong in score properties, which is designed to summarize basic information about the score. We frequently put them there (or in the footer) because we don’t have a better place for them, but they don’t really belong in either place.

To resolve the issue, I recommend a footnote mechanism, as Marc Sabatella (14 Aug. 2014, 14:22) and schepers (14 Aug. 2014, 14:38) discussed. Common needs that would be met by this include (a) extended information related to copyrights and (b) performance notes, and I’m sure there are others I haven’t considered.

I think most of the logic needed for footnotes is already in the codebase. If we break things down, a footnote consists of staff or system text (indicating that one should look for the footnote) linked to a text frame (containing the note itself), both of which already include an anchor to a given point on the score. First (or, in the case of choral music, second or third) page copyright notices would simply be anchored to the first measure. Positioning the text frame might be accomplished by combining the logic used for placement of the footer (though I can see how this might not work) with the “stacking” mechanism used for overlapping system text, tempo markings, and so forth (the latter would have to be modified so that the first footnote would appear at the top of the stack, rather than the bottom, but a switch to assign ascending or descending order shouldn't be too difficult). The mechanism for ordering rehearsal marks could be modified to support assigning each footnote an identifying mark (one asterisk, two asterisks, etc.) that is unique on its page.

New code that would be required would include the link between the staff/system text and the text frame (deleting either should delete both) and logic to prevent an endless loop of repositioning when adding a footnote takes up enough space to force the system to which it is attached onto the next page (which would also move the footnote to the next page, leaving enough space for the system to return to the previous page, bringing the footnote along with it and starting the cycle all over again). For the specific case of copyright information, there would need to be an override to force that text frame to the bottom of the stack (even if there are other footnotes which occur later on the page; a related concern is the possible [read: inevitable] attempt to add it twice on a given page) and access to the visibility setting for the associated staff or system text, which would also need to exclude that note from the series of identifying marks. (To simplify the user experience, it might be best to create two commands to access the two primary uses of the same underlying logic — possible labels might be “performance note” and “copyright information” or “labeled footnote” and “unlabeled footnote”, though I’m certainly not devoted to any of those suggestions, and the latter set might be unclear for users.)

Why do I think this better than some of the other suggestions? Adding a special box for a first page footer with copyright information doesn’t work well for the standard format of most choral music (as schepers pointed out — 14 Aug. 2014, 14:38) and doesn’t address performance notes (a function which, frankly, I’m astounded doesn’t already exist). Miwarre’s suggestion of page styles (25 Nov. 2015, 17:56) has some merit, but I believe it would be a lot more work than is necessary to resolve the issue of copyright information and would have limited utility beyond that for most users. Creating a framework that will accommodate future needs (25 Nov. 2015, 23:04) is valid, but a more generalized mechanism like I’ve described is different from a single-purpose fix for a narrow issue and, again, I’m not clear what other common use cases would be supported by a page style mechanism (aside from omitting headers on the first page of each movement of a multi-movement work, which I consider relatively uncommon in the current musical environment). The suggestion of a linefeed escape as a short-term fix (see shoogle’s comment of 26 Nov. 2015, 02:36) is a good one, but Jojo-Schmitz has a workaround that requires no additional code (see https://musescore.org/en/node/272883), so I’m neutral on whether or not it’s worth the effort. ChurchOrganist’s suggestion of extending support for metadata tags (28 March 2014, 11:09) also has some merit, but it doesn’t address the issue at hand, and chen lung correctly notes (13 Aug. 2014, 23:59) that the same issues we see with extended information about copyrights can also apply to information about composers and lyricists, which indicates that similar handling of that information — the summary in score properties and the details in text on the score — may be warranted.

Again, I apologize for the length, but I’m trying to be thorough. My hope is that the amount of detail I’ve included will help focus our thinking and possibly start us toward a solution to a long-standing deficiency.