Support Pages

[webern]

The current ScoreData looks like this, with no way to specify page layout (as far as I can tell/remember).

        class ScoreData
        {
        public:
            ScoreData();
            MusicXmlVersion musicXmlVersion;
            std::string musicXmlType;
            std::string workTitle;
            std::string workNumber;
            std::string movementTitle;
            std::string movementNumber;
            std::string composer;
            std::string lyricist;
            std::string arranger;
            std::string publisher;
            std::string copyright;
            EncodingData encoding;
            std::vector<PageTextData> pageTextItems;
            LayoutData layout;
            std::vector<PartData> parts;
            std::vector<PartGroupData> partGroups;
            int ticksPerQuarter;
            std::set<SystemData> systems;

            int getNumMeasures() const;
            int getNumStavesPerSystem() const;

            /// sorts all of the events, directions, etc.
            /// it is good to call this before writing to xml.
            void sort();
        };

Implement page layout in a manner consistent with the SystemData approach.

Open questions: should page breaks be specified by measure index, like systems are, or should page breaks be specified with system index?

[p-groarke]

Would it be possible to add them to the measures directly, similar to decorations? I find systems un-intuitive, having to go back and process all the measures. I wish systems were added to measures as well, though I think that's not how the spec works :)

For my needs, just a toggle on a system would be enough. I'm unsure how others use it. Whatever you choose is fine by me!

[webern]

A toggle on the system sounds like a good solution.

[webern]

Giving this some more thought.

	<xs:attributeGroup name="print-attributes">
		<xs:annotation>
			<xs:documentation>The print-attributes group is used by the print element. The new-system and new-page attributes indicate whether to force a system or page break, or to force the current music onto the same system or page as the preceding music. Normally this is the first music data within a measure. If used in multi-part music, they should be placed in the same positions within each part, or the results are undefined. The page-number attribute sets the number of a new page; it is ignored if new-page is not "yes". Version 2.0 adds a blank-page attribute. This is a positive integer value that specifies the number of blank pages to insert before the current measure. It is ignored if new-page is not "yes". These blank pages have no music, but may have text or images specified by the credit element. This is used to allow a combination of pages that are all text, or all text and images, together with pages of music.

The staff-spacing attribute specifies spacing between multiple staves in tenths of staff space. This is deprecated as of Version 1.1; the staff-layout element should be used instead. If both are present, the staff-layout values take priority.</xs:documentation>
		</xs:annotation>
		<xs:attribute name="staff-spacing" type="tenths"/>
		<xs:attribute name="new-system" type="yes-no"/>
		<xs:attribute name="new-page" type="yes-no"/>
		<xs:attribute name="blank-page" type="xs:positiveInteger"/>
		<xs:attribute name="page-number" type="xs:token"/>
	</xs:attributeGroup>

new-system and new-page attributes [...] Normally this is the first music data within a measure. If used in multi-part music, they should be placed in the same positions within each part, or the results are undefined.

I think this the reason that I hold the StaffSystemData information at the top-level of the score. So it can be authored once, and then can be placed in the the correct places when serializing. If I didn't do this, then you would be responsible for 'getting it right' by placing the same data in each part/measure as the spec requires.

I guess I'm thinking that to be on the safe side we might want

struct NewPageData {
   bool  blankPage;
   std::string pageNumber; // or int? but i ii iii iv?
}

Elsewhere in the MusicXML there is probably information about margins, page size etc. and I wonder if it that info should go into NewPageData also (someday).

We could place NewPageData into a SystemData that represents the start of a new page using, e.g. std::option (for the fist time).

struct SystemData {
//...
    std::option<NewPageData> newPage;
//...

But I wonder if it's unwieldy to have these down in the SystemData vector instead of at the top as a vector of PageData.

Hmm....