"number of pages" metaTag "$n" increases cumulatively for each part in export PDF of Score+Parts

• Jul 13, 2015 - 23:07

If I either download PDF including parts and view *-parts.pdf or if I locally export parts as PDF and view *_Score_and_Parts.pdf, then I notice that the value of "number of pages" metaTag "$n" increases depending of on total accumlated number of parts that exist so far into PDF generation.

Here is how $P/$n page tags are displayed when exported as PDF of Score+Parts both generated locally (e.g. attached) or generated online (temporary secret link: http://mus.cr/1HqNG1h) of a SATB example containing 2 pages for score and 2 pages for each part:

score:
1/2
2/2
part1:
3/4
4/4
part2:
5/6
6/6
part3:
7/8
8/8
part4:
9/10
10/10

So you can figure out that pattern. $n seems to be equal to the total number of pages of the current amount of parts that have been encountered so far into the pdf generation. I don't know what "expected behavior" should be, but I would expect that for a particular PDF file, the value of $n would be a constant equal to the total number of pages in that PDF. So in this example, I would expect $n should equal 10.

(Note: when generating *individual* PDFs of each part, I would expect $n to always equal the number of pages in each part, which in this example always equals 2, which musescore does handle correctly.)

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 13, 2015 - 23:18

This was discussed at some point and at least some were in favor of the current scheme. I am with you, though - I think it makes *much* more sense for each part to be numbered individually. When using the "Export Parts" option from within MuseScore, at least you do get the separate PDF's, which are all numbered correctly. But the new option to download score and parts gives you the much less useful combined file. I think either the page numbering should be changed, or else that option on musescore.com should give you a ZIP of the score + parts rather than the single PDF.

Reply

• Jul 13, 2015 - 23:27

The specific issue I'm criticizing here is how the value of $n increases based on the current number of parts encountered so far into pdf generation into the Scores+Parts pdf, causing $n=2 in score, $n=4 in first part, $n=6 in second part, $n=8 in third part, $n=10 in fourth part.

I would prefer you scheme of having parts be numbered individually (indeed there is a $partName metatag that could be used before $n/$P so there is no confusion). But my issue I'm raising here is separate from that.

Reply

• Jul 13, 2015 - 23:49

Let me try to be clear...I can consider two valid number schemes:

A) It would be perfectly valid for $n to equal the number of pages in a particular part (and $p's to be relative to the number of pages in that individual part).
B) It would be perfectly valid for $n to equal to equal the total number of pages in all parts (and $p's to be relative to total number of pages in the pdf of score+allparts).

But I see no valid reason whatsoever in the current situation of $n increasing cumulatively based on the number of parts encountered so far into a pdf.

Reply

• Jul 13, 2015 - 23:33

I can suggest another way to accommodate a variety of page numbering systems, which is to simply define a few new meta tags for pages, e.g.:

$partn = the number of pages in this part, regardless of the total number of pages in all parts.
$partP = the current page relative to the number of pages in this part, regardless of the total number of pages in all parts. Likewise for $partp to correspond to $p, and $partN to correspond to $N.

Reply

Do you still have an unanswered question? Please log in first to post your question.