[MusicXML] new-page on first measure shouldn't create one more page
Read my Technology Preview comment 3 sept. 2014.
MuseScore 2.0 does honor the page break from the title page as a blank page. This is different from MuseScore 1.3, Sibelius and Finale.
Compare the results of the imported "I've Got The World On A String2.xml" in all programs.
All results attached.
Rob
| Attachment | Size |
|---|---|
| I've Got The World On A String2.xml | 80.91 KB |
| I've Got The World On A String2 (1.3).mscz | 5.17 KB |
| I've Got The World On A String2 (1,3).pdf | 60.51 KB |
| I've Got The World On A String2 (2.0 Beta1).mscz | 8.15 KB |
| I've Got The World On A String2 (2.0 Beta1).pdf | 42.09 KB |
| I've Got The World On A String2 Sibelius.pdf | 31.84 KB |
| I've Got The World On A String2 Finale.pdf | 675.87 KB |
Comments
Link to original forum post: http://musescore.org/en/node/32036
Tested with NF as well, which also discards the new-page attribute.
When opening the xml file in MuseScore 2.0, the page break is nearly hidden at the top. Selecting it and removing it solves the formatting issue. But better to change it in the code.
Which means to ignore the <print new-page="yes">, right?
Correct, at least the very first one.
As I already said in the forum thread ( http://musescore.org/en/node/32036#comment-134091 ), I do not understand the issue.
If a page break is there in the MSXML file, I see no reason to disregard it. If the user of the MXML file does not like it (or it does not suit his habits), then one may assume the MXML file has been originally created for different needs and the final user will have to tailor the results according to his needs.
In particular, having a title page separate from the music page is a well possible and reasonable layout; the proposed change will make impossible to read such a layout from an MXML file.
Thanks,
M.
P.S.: the page break icon being almost out of the page in the imported score is due to the margins of the page being unusually small (the right margin is less than 1mm!)
@Miwarre A valid question which I'd like to answer on.
My rationale: user experience beats correct interpretation, or improving the migration path to MuseScore trumps honouring MusicXML to the detail.
Earlier this year, tens of thousands of musicians joined a mooc named Write Like Mozart. In the very first lecture, a set of MusicXML's were provided: classicalcomp-lecture_slides-Week 1-Week1_XMLexamples.zip. The lecturer advised to use NF or MS to open the MusicXML files and perform the task.
This is how it looks in MS 1.3
This is the result in NF, similar to Finale or Sibelius.
It was a pity to see people using other notation software because the import was not good in MuseScore. The MuseScore user experience for those thousands of students was: meh.
Next year when the course runs again and people will be using MuseScore 2.0, this will be the result.
Much better! One detail left which is the page break. Yes, it's in the MusicXML, but none other software respects it because it's basically not meant to be there. It's a flaw caused by bad MusicXML export. Hence this request.
@Thomas: thanks for the explanation: things are clearer. I still disagree, though; if some other notation program has "bad MusicXML export" and inserts spurious page breaks, it is that other program's problem, not MuseScore's.
If the page break is "basically not meant to be there", it should not be there. If it is there, it shall be honoured.
Asking an algorithm to guess the intentions of the creator of the original file is a sure recipe for trouble. In particular in this case, because that specific page break may easily have all the reasons to be there, as having a title page separate from the music page(s) is a legitimate -- and not unusual -- layout solution.
Thanks,
M.
Yes, I agree - don't break the ability to have a separate title page just because some other program doesn't export correctly.
Ok guys, I rest my case ;)
What was the flawed software that produced the page break even though it wasn't meant to be there? Would it be possible to special case that? I do agree the user experience is mire important than correctnss, but users of non-flawed need to be considered to. If all software out the unintended page break there, then of couse we should ignore it. But if it's just one program that does this, and it's a program with enough users (or whose MusicXML files have enough users), then a special case to work around the flaws of that program seems fine. That way users of other programs are not inconvenienced, but files from the flawed provram still import as intended.
The notation program that exports a page break for the first system is Sibelius.
Since converting MXML into .sib format used in the very convenient app "Avid Scorch" for the iPad may become important opening MXML in Sibelius without the need to make manually corrections may become important as well. Whether compatitor Sibelius is important enough to give users the possibility ignore this page break during import is up to you guys of course. Just let me know what your strategy is so I can anticipate :-)
OK, but I thought you said the problem had to do with *import* of files that *created by Sibelius*. Are you now saying there is also a *separate* problem with *export* from MuseScore? Could you explain that problem? Or perhaps create a separate issue to explain that problem - and whether it's an actual bug in MuseScore or just something you want MuseScore to do specially when you know the file is going to be imported into Sibelius, in order to work around a bug in that program. This is, apparently, what you are asking for on import.
In any case, the idea of a feature request to add a "Sbelius bug-compatibility mode" on *import* makes sense, since is indeed a popular program. Do you know if this bug in Sibelius that causes unwanted page breaks to be saved in scores that do not in fact have page breaks after the title is present in all versions of Sibelius or just some - and if so, which versions of Sibelius have this bug?
Ok, this is turning to a new direction. To put it into a broader perspective, there is no notation software which produces flawless MusicXML files. Blame it partly on the non-strict specification of the MusicXML format. So as MusicXML import in MuseScore has been greatly improved, we are now starting to receive cases introduced by badly created MusicXML files. Something which was to expected.
On the latest MusicXML gathering at the MusikMesse this year, there was a proposal to create an open source MusicXML sanitizer (for more, see slide 34-46 including a bad MusicXML example coming from MuseScore). It's unsure what the status is of the MusicXML sanitizer, but we've come to the point now where we could contemplate to add a MusicXML sanitizer into MuseScore.
As we gather information on the software and version which produces bad MusicXML, we could further improve the MusicXML import in MuseScore. It will benefit the user experience of people migrating their scores to MuseScore.
It is meant for importing in Sibelius. I can't say missing it is an exporting bug from MuseScore. I did analyze all 6632 MXL files from the Wikifonia. Although ca 4500 are created by MuseScore and ca 1000 by Finale and the rest by a lot of other notation programs only ca 280 did come via some relation with Sibelius ( the name somewhere in the headers mentioned software, but didn't seem to be directly created from Sibelius). Only ca 25 of these 280 did contain the new-page at the first page, so the rest (6607) didn't have the new-page indication.
Nevertheless if exporting files into MXML with the present Sibelius it will always add new-page at the first page and if importing one of the 6607 files without new-page it will always creates a mess between headers (title, composer etc) and music unless you add new-page. So Sibelius seems to rely on a new-page presence for good results.
It surprised me that Thomas did show an example as well. So I just guess that the file he used is created by Sybelius. It shows the importance of having some Sibelius compatibility. Since I wanted to create files for the app "Avid Scorch", which is the only iPad app I know of which has a decent transpose function built in to transpose all music including chords to any key and show any musical representation for any instrument, I import MXML files into Sibelius to save them as .sib for use in Avid Scorch. I only want to use Sibelius as a quick and dirty conversion tool (batch operating) to generate the files without manually correcting the files. This meant I need the new-page indication at the first page to satisfy the Sibelius needs.
Having discussed this with Myriad's "PDFtoMusic Pro" which I use to convert all by BIAB created PDF files into MXML, they also have introduced this new-page at the first page in their newest version (Beta5). I guess they saw it had a good influence on Finales representation as well. The new PDFtoMusic Pro has also implemented on my suggestions all the available chords used in BIAB. So they now produce a very good result for direct clean conversions, although I still need to filter the results myself afterwards, but that is an automated batch process. I studied also the present MuseScore import of BIAB files (.mgu) but the result isn't usable to create a direct usable correct representation in MXML.
My personal feeling now is that Sibelius should change their methodes. But this is only based on the fact that they seem to be the only one who uses this new-page at the first page. However my knowledge about the whole issue if you analyze MXML, all important excisting notation programs, all parameters that reproduce the good positions of title and music at the first page is too limited to give a good advice. I'm just a pragmatic user tryïng to get a quick result.
The Thomas example showed also the still missing title and composer in MuseScore 1.3. That didn't surprise me at all. The mess created by having title, poet, composer and copyright in the header and then add this sometimes again as credit-words is unbelievable. This creates another problem at the same time directly related to this issue. Again here a problem has been introduced (it seems) in the new MuseScore 2.0. That was a problem which I filtered in my own batch process to solve it for Sibelius and MuseScore 1.3 and Finale. I'm investigating what happens and why again now the distance between title and music is too little. (It is overlapping)
Conclusion: I'm not happy with MuseScore 2.0. May be the best way to anticipate is to just add a separate import option to ignore new-page. In a MXML file the new-page for the second and more pages will never be at the correct position anyway. The default should be to ignore it. As already beïng said ignoring new-system should be a separate choosable option, since many users like to keep the original system format rather then using automatic varyïng the number of measures in a system. The default should be not to ignore it.
Will be continued.
So you basicylly need a 'Sibelius bug compatibility mode' on (M)XML im- and Export, ignoring the first page break in import, but adding it on export?
'Sibelius bug compatibility mode' is not the right answer, since there will be many notation software packages and versions to consider. So you would end up with multiple 'XXXX version zzz bug compatibility' modes.
Thinking more about it, this is most likely out of the scope of MuseScore as it will become technically really challenging for maintaining all the exceptions in the MusicXML import. A MusicXML sanitizer deployed as a web service makes more sense.
Thos who need/have that page break could manually add it before export resp. remove it after import?
The only issue I see is that on the example gived that page break was pretty much well hidden
I believe it should be noted there is always a plugin to fix Sibelius and Finale to import and export to the latest "official" version of xml. Even people with the latest version of their prospective program should realize that the internal music xml import/export can be somewhat broken if not outdated and should use these plugin's anyway if they use xml.
http://www.musicxml.com/
Yes, I realized it could quickly get out of hand trying to support all the different bugs in all the different versions of all the different programs out there.
But so far, it's just this one particular bug in one particular program that seems to be the issue. So if this really is considered important, we *could* add an option just for this.
I don't understand the claim that Sibelius requires a page break when it imports files, though. I've imported many MusicXML fiels created by MuseScore before, and never seen any problem at all. If there is a problem, it must be only happen on export from Sibelius - and since I have only a trial version of Sibelius, I can't test this.
Or maybe the bug that happened on import into Sibelius is only present in very old versions (Sibelius 7.5 is current; I using 7 which was released over three years ago)?
If it's possible to work around this Sibelius bug without inconveniencing everyone else, I'm perfectly happy to see it done. But so far, I'm still not really understanding the situation.
Some more facts.
* "Ignoring the new-page on first measure" would not remove the possibility to have a blank (no music) page first. MusicXML has a blank-page=yes tag for this. See http://www.musicxml.com/UserManuals/MusicXML/MusicXML.htm#CT-MusicXML-p…
* "ignoring the
new-pageon first measure" is a way of speaking. The new page is actually created for the first measure: it's the first page... Also note thatnew-pagehas a different meaning than "page break" in MuseScore.*Sibelius 7 (no dolet plugin) doesn't use blank-page attribute but put a
new-pageattribute. So a score with or without a title page from Sibelius looks the same when importing back to Sibelius or Finale. The MusicXML is almost the same too. In both Sibelius and Finale "ignore anew-pageattribute on first measure."* Finale (2012, no dolet) does use the blank-page attribute when exporting a score with a title page. It doesn't use a
new-pageattribute on the first measure. Importing back a MusicXML with a blank-page does work in Finale *and* Sibelius.I don't see any problem to "ignore the first
new-page" if we use the blank-page attribute.A Sibelius or any other "compatibility" mode should not be our business. Happy users or not.
@Robipad It's your choice to use Sibelius and Scorch but the MuseScore songbook will have transpose soon :)
Test files from Sibelius and Finale
Thanks for the clarification. I figured there had to be more to this!
Hi Guys,
I like to add another issue and some clarification. The issue is that the distance between title and first is zero in MuseScore 2.0 while its shouldn't. To show you I added a chord in all AWESOME files and attached them.
Secondly I bumped into the conclusion that although new-page seemed to be needed for Sibelius it also will accept without any addition and show the same results as with new-page. I had mistakenly strong believe that only new-page did show a good result in Sibelius. This idea was created because all my PDFtoMusic Pro results did start the first system with I discovered. That's why I addedone more AWESOME file with new-system.
To compare the results of all files opened in Sibelius and Finale I added them in some zipped files. I will not comment yet on all the individual results, judge for yourself.
My conclusions sofar are: MuseScore 2.0 needs to ignore the new-page for the first system. Secondly a proper distance has to be created between title/composer space and first system
Fixed in eff8391c5c
Great fix Nicolas!
Didn't mean to change the status of this issue.
Does this mean that both problems I summarised in #25 are solved and will be implemented?
@robipad the main bug report of this issue has been fixed and you can test it by downloading a nightly build. As for the other problems you raised, open a new bug report for each with the steps to reproduce. Thanks.
@Thomas, thanks took me a while before I found the Nightly Builds, then it worked very well. I also discovered I had to set the style at 7 (Vertical frame bottom margin) to solve my problem mentioned in #25 about distance between header and music. So this is solved as well, sorry about mentioning it. Thanks, great job!
Automatically closed -- issue fixed for 2 weeks with no activity.
Hi,
I like to reopen this issue.
Importing the musicXML file with a new-page in the first measure is a solved problem for 2.0.2
by not honoring it anymore. However when converted by MuseScore 1.3 into .mscz it seems it stays not honored in MuseScore 1.3 but when imported as .mscz but it becomes honored again in 2.0.2.
In other words all files when converted ( in 1.3 ) from musicXML into .mscz do show up in 2.0.2 with an extra blank page.
However imported in 2.0.2 as musicXML (with new-page) and converting it with 2.0.2 do apparently convert it correctly by removing the new-page in the .mscz file.
So what happens all my 6000 converted to .mscz files ( by 1.3) and imported as .mscz in 2.0.2 show up with a blank page. Worse also if imported into the iPad app they show a blank page as well.
It seems that many more users suffer from this problems since I noticed several files in "Discover" suffer from the same problem, an extra blank page.
So my conclusion is: 1.3 did never honor the new-page ( from the first measure) neither from the musicXML nor from the .mscz file. So it wasn't removed during the conversion as well.
In 2.0.2 it is not honored (anymore) if imported from musicXML but it is still honored if imported from .mscz. It is also honored if imported into the iPad (an Androïd app I guess) However when converted from musicXML into .mscz by 2.0.2 the new-page from the first measure is apparently removed from the .mscz file.
So in order to correct all my 6000 files I need to convert them again with 2.0.2 to get the new-page removed from the .mscz files. (However the 2.0.2 batch-plugin doesn't seem to function which is another issue but is cruxial to me to correct all these files)
However if you like all users files from "Discover" to show up correctly, also the new-page shown with the first measure of a file in .mscz should not show up neither in 2.0.2 or in the iPad or Androïd app.
Rob
I'm not really understanding. If 1.3 already imported the file incorrectly, it's kind of too late for 2.0 to retroactively undo that. As far as I know, it just sees a page break that it should honor like any other page break.
But maybe I am not understanding. Can you post a sample score (MusicXML and./or MSCZ from 1.3) and precise step by step instructions to reproduce what you think the bug is?
To re-convert your files in 2.0, just use a shell script - MuseScore can be invoked from the command line.
I'm not sure if you understand the original posted issue which seemed to be solved.
Sibelius files if exporting a musicXML add "print new-page" to the first meausure. This, if imported in 1.3 does NOT add an extra new page after the title. It also does NOT import a new page in Sibelius and also it does NOT add an extra new page in Finale. Title and music from the first page stay together. So far so good. Converting musicXML to .mscz did not change this in 1.3. Sibelius is the only one which does that as far as I know.
However in the first versions of 2.0 due to this print new-page in the musixXML file title arrived at page 1 and the first measure at page 2. We had a discussion and then the issue has been solved in 2.0.2. So also if importing the musicXML into 2.0.2 title and music stay together now with the new-page info.
However what I didn't check is if I imported the by 1.3 saved .mscz file from that musicXML what happened with the info new-page during the saving. If you save it in 1.3 it also saves this new-page information in the .mscz file. Opening that saved file in 1.3 does not change the representation. However opening the same .mscz file in 2.0.2 does add a new-page again between title and first measure. So here again 2.0.2 does separate title and first measure again which had been solved for the musicXML import but not for the .mscz import.
However if you import musicXML in 2.0.2 and also save it as .mscz in 2.0.2 it keeps title and music together. So saving it as .mscz in 1.3 seems to save the new-page info but saving it in 2.0.2 automatically removes the new-page info which is ok.
The matter is should the new-page info if present in whatever format in the first measure separate title and the first measure into 2 pages? We agreed upon it should NOT. That has been corrected for the musicXML input in 2.0.2, it has not been corrected for the .mscz input. Not in 2.0.2 and not in the apps. It is an issue which in time will disappear if all newly converted .mscz files are converted in 2.0.2. since that conversion automatically seems to remove the new-page info for the first measure.
Rob
I didn't understand the original issue fully at first, but thought I did in the end. It had to do with the fact that MusicXML has a "new-page" element that is different from a page break in MuseScore, so every new-page need not necessarily translate into a page break.
However, I definitely don't fully understand what you are saying here, which is why I'd like to see a score and precise steps to reproduce what you are seeing, so I can understand if it is really a bug or just how it is.
To me, if an input MSCZ file has a page break - not a new-page element, which MSCZ files have no concept of - attached to the title frame, then that page break must be honored. It would be a bug if it *wasn't*.
However, maybe in 1.3 page breaks are not normally attached to frames, in which case, we might be able to safely special case "page breaks attached to frames in 1.3 files" and ignore those. I don't know, because I would need to see an actual file to understand.
OK. We start with: "A fool such as I.xml" containing: .
Then convert the xml file into "A fool such as I.mxl" (via a WINZIP bat file)! (this is not relevant for the conclusion but I had all my files converted into mxl by default, so I used the mxl example)
Then open "A fool such as I.mxl" in 1.3 and see the result in "A fool such as I (opened as mxl in 1.3).pdf" the result is OK
Save the mxl file in 1.3 to .mscz: "A fool such as I (mxl converted into mscz in 1.3).mscz" and see the result in 1.3 as "A fool such as I (mscz result after conversion mxl into mscz in 1.3).pdf" the result identical and OK.
Import this 1.3 mscz file in 2.0.2 and see the result in "A fool such as I (in 1.3 saved mscz opened in 2.0.2).pdf" and here the result is NOT OK.
So it seems that the mscz file still contains the new-page info. The same applies if you open this mscz file in the apps at an iPad or Androïd tablet.
Then open "A fool such as I.mxl" in 2.0.2 and see the result in "A fool such as I (opened as mxl in 2.0.2).pdf", the result is OK (this has been implemented via this "issue" during 2.0.2 developement).
Now save this mxl file as mscz in 2.0.2 as "A fool such as I (mxl converted into mscz in 2.0.2).mscz" and see the result in "A fool such as I (mscz result after conversion mxl into mscz in 2.0.2).pdf". Now the result is OK, so the new-page information has apparently been deleted. Also when you export the file as .xml again: "A fool such as I (exported in 2.0.2 as .xml).xml" the has been changed into . The same is valid if you export it in 2.0.2 as mxl again (see: "A fool such as I (export from 2.0.2).mxl), then also in the exported mxl "new-page" info has een deleted
In other words in 2.0.2 the matter has been solved for all situations except if it imports a mscz file from 1.3 which still contains the "new-page=yes" information which separates title and first measure. I hope you now can figure out what I want to explain. All mentioned files have been zipped and attached.
Rob (A fool such as I :))
Thanks for the info.
Again, "new-page" is a MusicXML-ism. MSCZ files do not contain any such elements; they contain "page breaks", which are different from MusicXML "new-page" elements. And the MSCZ file contains a page break on the title frame. And page breaks in MuseScore mean, start a new page after this. So 2.0 really is doing what it is asked to do here.
I guess what is happening is that 1.3 put the page break there, but that page break was not actually honored - a bug, I would say, although it happened to be what you wanted in this particular case. What isn't clear to me is if 1.3 *never* honored page breaks on frames or if this one was special somehow. It doesn't look like it is possible to add one manually in the usual ways, so maybe it just didn't support them at all.
Anyhow, *if* it is the case that 1.3 never honored page breaks on frames, then I think 2.0 can safely ignore them in 1.3 files as well. But I have no idea if that assumption is correct; I'll leave that to someone else to figure out.
I just figured out that also 1.3 removes new-page in the first measure if saved or re-saved as MusicXML. Then opening the newly saved MusicXML does produce a MSCZ file without the page-break, so then if opened in 2.0.2 the problem has gone.
I think I will remove all new-pages for the first measures in all 6000 files and batch-convert it in 1.3 (that functions) into new MSCZ files. It solves my problems and what MuseScore 2.0.2 decides to do leave to "somebody else" to figure out. Just please let me know.
Rob
I'm talking about MSCZ only here.
If a MuseScore 1.3 file contains a page break after the first frame, it will be honored in 2.0.2. We could eventually fix the import of 1.3 files in 2.0.2 to delete this page break...
There is a bug in MuseScore 1.3 since it didn't honor a page break after a frame in a MSCZ file.
About MusicXML:
MuseScore 2.0.2 MusicXML import is correct. Nothing to do.
In any case, this is all loosely related to this bug report. So I close this bug report. Feel free to open a new one for the import of pagebreak after a vertical frame in MuseScore 1.3 files.
Last point, if you intent to use the final files in the mobile apps, it would be better to get rid of MuseScore 1.3 completely in your workflow.
I agree. But before getting rid of 1.3 I first need to figure out how the plugin batch file functions in 2.0.2. Untill now it didn't function or at least I don't know how to get it running.
Secondly since importing most xml files in 2.0.2 are stopped because of found mistakes (which can be ignored) I'm now afraid that batches don't really work anyway in 2.0.2 while 1.3 is not so sensitive for small mistakes, unless you can force the batch to ignore found import mistakes? Can I force the batch to ignore automatically mistakes during conversion?