metatag $n in PDF of parts+score should be constant equal to total number of pages, not cumulatively increasing with each part

• Jul 14, 2015 - 01:11
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

In PDF of score+parts (either generated online or locally), the value of metatag $n currently increases cumulatively based on the number of parts encountered so far into that PDF. According to discussion https://musescore.org/en/node/68926, the expected agreed behavior is that $n should be constant inside a PDF of scores+parts, equal to the total number of pages in that pdf. This is an implementation bug, not a feature request.

Here is how $P/$n page tags are displayed when exported as a single PDF of Score+Parts both generated locally (attached .mscz and pdf) or generated online (second pdf, has identical bug) of a SATB example containing 2 pages for score and 2 pages for each part:

$partName & page relative to number of pages in that part in individual pdfs Current buggy values of $P/$n in pdf of score+parts Expected Values of $P/$n in pdf of score+parts
score 1/2 1/2 1/10
score 2/2 2/2 2/10
soprano 1/2 3/4 3/10
soprano 2/2 4/4 4/10
alto 1/2 5/6 5/10
alto 2/2 6/6 6/10
tenor 1/2 7/8 7/10
tenor 2/2 8/8 8/10
bass 1/2 9/10 9/10
bass 2/2 10/10 10/10

In this example, the value of $n in pdf of score+parts should always equal 10 (the total number of pages in the pdf).

Attachment Size
test_$n_on_all_pages_on_all_parts.mscz 7.64 KB
test_$n_on_all_pages_on_all_parts-Score_and_Parts.pdf 23.66 KB
test_number_of_pages_n_on_all_pages_on_all_parts-parts (1).pdf 25.13 KB

Comments

• Jul 14, 2015 - 09:39

I belive the fix is easy, so I'm assigning to myself. During export, after appending all the score parts together into one big score, I just need add a line to tell the combined score to update. That update would hopefully set the value of $n to total number of combined pages.

Reply

• Jul 14, 2015 - 11:44

according to https://github.com/Jojo-Schmitz/MuseScore/commit/656170b43314585440b82e… you are setting the page numbering "to be the same as if score and parts had been generated separatly". So is that the expected behavior, and not numbered relative to total number of pages? I apologise as apparently I made a mistake understanding expected behavior.

Oh well, maybe there need to be a new set of $p, $P, $n, $N tags defined...one set for page numbering relative to each part, and one set for page numbering relative to the combined score+parts pdf.

Reply

• Jul 14, 2015 - 14:56

The expected behavior is not clear so far.

1/The current behavior is to number all the pages in order (1,2,3,4,5etc..). There is indeed a bug with the total number of pages but it's fixable.

2/Another requested behavior is to number the pages per part (so 1,2,1,2,123). This behavior is more or less already supported if one export the PDF for the score and then the PDF for the parts while the other behavior cannot be supported.

I know Jojo prefer 2/. That's why he made a pull request. I prefer 1/ (minus the bug of course) but mainly because we can have both if we implement 1/ for "Export Parts" but I don't have a strong opinion about it so I would like to have more opinions from actual users of this feature.

@ericfontainejazz, considering there are no bugs, which behavior would you prefer?

Regarding easy bugs, we have a tag here https://musescore.org/en/project/issues/musescore?keys=&status=All&prio… but it's currently empty :( You can alwaus join #musescore on freenode.net to have a chat and find something to work on. https://kiwiirc.com/client/irc.freenode.net/?nick=musescore|?#musescore

Reply

• Jul 14, 2015 - 15:45

I too prefer "2", but agree that it is nice to have both, and the individual parts are already numbered individually, so I don't care so much what the numbering is in the combined PDF, which I would simply not use.

My only request, then, would be that the new option to download parts from musescore.com actually downloaded the individual parts - perhaps a ZIP file contianing them all. I think that's a better solution even if the combined PDF used "2".

Here's my use case, which I imagine is typical:

I direct a jazz big band - 17 musicians. I want to upload my score, send out a mass email to all 17 with a link to that score, and tell them they can download and print their own parts. As it is, they would all get the same giant PDF. In order to print their own parts, they would have to manually scroll down to find their parts, make a mental note of which page numbers they are, enter those number manually into the print dialog, then print their parts. And unless the combined file had page number as per "2", they would see what appeared to them to be random page numbering ("why is the second page of my part numbered 47?")

Instead, if the download was a ZIP of the individual parts, they could download it, unpack, and print their part. Easier, and the page numbering would be right.

Reply

• Jul 14, 2015 - 16:04

I'm not sure I ever made it a PR, currently it isn't one for sure, just a branch in my MuseScore fork. The current behavior is what keeps me from using those score+parts.pdf, instead I use the export parts and the batch convert plugin and live with the fact that I have to distribute different files to different members of our ensemble (choir and band)

Reply

• Jul 14, 2015 - 15:49

Oh, and Eric: in my experience, very little is "easy" until you learn some basics of how the code works, so there is a learning curve almost no matter what. So the "easy" bugs are, I think, the ones that interest you enough to stick with it. With that in mind, I'd point you to http://musescore.org/en/issue-hit-list-marc-sabatella and see what floats your boat. Maybe ask on the IRC channel to see if there is a particular reason *not* to try a particular bug. I will say that everything listed under "crashes and corruptions" is not easy or it would have been fixed by now (they are normally dealt with more promptly).

Reply

• Jul 14, 2015 - 23:32

I prefer 2\, because:

  • 2\ gives consistent numbering regardless of whether the user is printing individual parts or printing score_and_parts. I understand that having one numbering scheme be used for indivual parts and another numbering scheme be used for priting score_and_parts would accomodate both numbering systems, but I honestly think that having page numbers in individually pritinted parts not correspond with page numbers in score_and_parts would cause more confusion than it is worth. (E.g. lets say the band leader prints out score_and_parts.pdf thinking that is the most appropriate pdf for the leader to print out while all the musicians print out their individual parts, and suppose a musican is missing a page or asks the leader about something relative to page # on his/her part. With 2\ the leader would more quickly be able to identify that page the musician is talking about, but with 1\ would have to do some artithmetic or manual counting.)
  • Most importantly \2 strictly adheres to WYSIWYG behavior, while 1\ violates WYSIWYG behavior (even though minor), which I see is a strong point of musescore. With 1\, what you see in the editor in parts view is not what you get when you print score_and_parts, while with 2\, what you see in the editor in parts view is exactly what you get when you print either individually and score_and_parts. The only way to both have \1 and adhere to WYSIWYG is to redefine metatags for page numbers (or define a new set of tags) to exactly refer to accumulated page numbers of parts_and_score, which would need to be displayed both in the editor and printed. But having two sets of metatags would require support for both in the code, which brings me to:
  • 2\ has simpler code, because 1\ requires an additional initial pass through the entire list of scores & parts in order to calculate the total number of pages before rendering (at least that was how my quick fix was coded). For large scores on older machines, this might be an issue if metatags for 1\ need to be supported in editor mode: e.g. if I am editing one part in the parts editor, I could potentially add enough notes to cause the score's page layout to overflow to a new page, which would mean the page numbers for whatever metatag might need to be updated, which would require a recount of the total page numbers of entire score+parts, which would dirty every single page of every part & score, which would necessitate a re-render even if I click on another part that hasn't been modified. Just to account for correct total page numbers in editor view.
  • (Almost) all printers have an option to print real page numbers, so users that really want 1\ for printed score_and_parts can simply enable the option on their printer. Then musescore doesn't have to accomodate both options.

Sorry for the essay, but after much thought, I'm personally very much on side /2.

Regarding download from musescore.com, I would prefer an option for individual parts seperately as non-compressed pdfs in addition to the current option of scores_and_parts.pdf uncompressed. The reason I don't want zip is because I worry that many mobile devices do not have an unzip program installed by default, but (almost) all smartphones and all browsers (with pdfjs) will display a plain pdf without having to mess with unzipping to a folder (yes, I do deal with musicians with smartphones who are not technically savvy enough to be able to unzip and locate the unzipped files in their smartphone filesystem). So if I'm making a score that is not finalized, I can atleast text/email the musicians a url where they can get individual pdf parts of my most-up-to-date revision to practice or look at quickly. I don't think the small amount of space & bandwidth saved by zipping a pdf is significant and worth the hassle in this day and age. Actually most browsers do support a system for seamless compression/decompression of http downloads - https://en.wikipedia.org/wiki/HTTP_compression - I think implementing support for that would be preferable than providing zip downloads.

Reply

• Jul 15, 2015 - 16:07

Ok. I'm outnumbered and I was not really convinced myself... so let's implement 2/

@ericfontaine, for your mobile friendly friend, I know a super app that works great with MuseScore.com! and can display and play parts. It can even transpose them and doesn't have many buttons! https://musescore.com/apps

Reply

• Jul 15, 2015 - 18:10

And speaking for myself anyhow, $n works as I expect. Each part's "$n" value is the number of pages in that part, so each part within the combined PDF says "1 of 3", "2 of 3", and "3 of 3" regardless of which part we are looking at. In other words, the same as the individual PDF's, so the same results occur whether I print all parts at once from the combined PDF or each band member prints his part from the individual PDF. Works for me!

Reply