More page number control
1. Suppress page number on specific pages, e.g. to allow fold-out content (11x17).
2. Change page number on specific pages, e.g. to allow blank back.
3. Additional page number formats that can change within score (e.g. i, ii, iii, A, B, C, etc.), to allow front/end matter.
4. Simplified treatment for creating cover page (it typically will have a blank back, followed by page i or 1).
5. Allow 'zero' as initial page number so that 2nd page begins with 1 (same argument for allowing negative page #s if multiple front-matter pages should omit page #).
Perhaps many of these publication-management issues are being addressed in 2.0.
Comments
Indeed, there have been quite some improvements on this topic in the trunk. Don't hesitate to check out the nightly builds. See http://musescore.org/en/handbook/comparison-stable-prerelease-and-night…
If you encounter crashes or have requests to improve the trunk, don't hesitate to post it in the issue tracker.
In reply to The trunk by Thomas
...but I don't think the trunk contains (yet?) any of the suggested additions.
Personally, I find point 1) the most important, as it is quite complex to address in any other way (it may also address point 2) by itself).
The other points, relative to compound publication contents, are of course nice to have but, as MuseScore is not a word processor or a DTP package (and it will not be for a long time), my feeling is that it is by far simpler and more flexible to address them through separate files, using more appropriate tools for front and back matters (sparing coding resources for the musical notation points still pending).
If the final intended result is a distributable PDF file, I have found very useful a PDF manipulation tool like PDF Split and Merge to combine (parts of) multiple PDF files into a single one (also via command line or batch/script files).
M.
In reply to I may be wrong... by Miwarre
I agree that there are other ways to accomplish many of these tasks, but on the assumption that MuseScore might eventually want to support more, I'd take the approach of first implementing the ones that cannot easily be accomplished that way.
In reply to I agree that there are other by Marc Sabatella
I understand and agree with the points above about MuseScore's intended breadth of functionality.
On the other hand, it can be hard to predict how difficult a particular implementation task will be. Adding a seemingly simple feature might require a nightmare of interconnected changes; while adding what seems to be a huge new capability might be a relatively straightforward extension in one part of the code. So when making my feature requests, I have tried to be agnostic about the practicality of a given change, and simply listed the things that caused me the most heartburn as I've used MuseScore for the tasks I had at hand.
I might add that my focus remains on MY intended use, rather than a particular MuseScore developer's intended use. Each user has a different slant on what is important. Things that seem peripheral to some users will be showstoppers to others. In my case, breaking up my scores into different parts, created and managed by different tools, was far less convenient than using the available MuseScore tools in their limited ways, and accepting those limitations. So I've created my front matter etc. using vertical frames. (I deal with page numbers by turning them off and generating them using Acrobat.) I do feel that relatively minor changes could address many of these needs well.
At any rate, if somebody does decide to improve page number management (or any of the many other feature request topics), they might approach this through incremental, limited tweaks; or through a more systematic redesign. If somebody DOES decide to tackle an issue in a broad, clean-sheet way, then it can be helpful to have a laundry list of possible needs/uses/features, including some that go outside the box. At least that's been my experience.