Font issue in MusicXML export

• Feb 18, 2011 - 03:07
Type
Functional
Severity
S4 - Minor
Status
closed
Project
Tags

See attached score in either 1.0 or trunk (tested with 4003). Export MusicXML and try to import into Finale or Sibelius. Staff positions are a complete mess. While it's possible those programs are both wrong and MuseScore is right, I tend to doubt it.

Attachment Size
dusk.mscx 1.11 MB

Comments

Marc,

thanks for reporting this.

As I don't have access to either Finale or Sibelius, it is a bit hard for me to guess what the issue is. Could you also attach one or more screenshots showing the mess ? If possible I'd also be very interested to see the MusicXML generated by Finale or Sibelius (at least the part that describes the staff spacing).

Priority for MuseScores MusicXML I/O has always been
1) get the features exported/imported
2) get positioning information correct
We obviously haven't made much progress on #2, but that should be improved in future versions.

Thanks, Leon.

Here are screen shots from Finale and from Sibelius. Finale shows a huge gap between the first two staves, and the staff names are all so far above the staves they label that they look like they are labeling the previous staff. Sibelius appears to consistent spacing between staves and staff names positioning, but it for some reason thinks it can fit more systems per page than it really can, and they overlap. MuseScore itself seems to import the XML file it created just fine. I included Finale's XML output, but Sibelius doesn't provide that facility except as an extra-cost option. MuseScore's import of Finale XML's file looks good at first glance, but tons of notes are missing that were definitely there in Finale.

BTW, I don't actually own Sibelius, but the demo is free and provides pretty much all functionality except the ability to save files.

Attachment Size
finale.xml 1.7 MB
finale.png 724.99 KB
sibelius.png 298.74 KB

Marc,

thanks for pointing out the posibility to use the Sibelius demo. I download and installed it and am able to reproduce the issue. E.g. the demo file bach-bc2 exhibits the same behaviour when exported as MusicXML and imported into Sibelius. I also managed to reproduce the issue using a shorter file by creating a score with nine parts. As soon as this grows into the second page, the issue pops up.

Unfortunately, the MusicXML file produced looks correct to me and I have not yet been able to find out what causes the incorrect display in Sibelius. Solving the issue will take more time ...

Regards, Leon.

While testing the MusicXML import/export options (#13451: [trunk] MusicXML: optionally ignore layout information on import and #13452: [trunk] MusicXML: optionally suppress layout information on export) I found import into Finale Notepad seems to work best when MuseScore does not export layout and only exports manually added breaks. Same remark applies to Sibelius, although Sibelius itself already has options to ignore layout contained in a MusicXML file, which have the same effect.

Hi Marc,

I am verifying old issues to see if they still need fixing before 2.0. This one I cannot reproduce anymore, the MusicXML output of both MuseScore 1.3 and the current trunk contain correct system- and staff-distance values and import correctly into Finale Notepad 2012.

Can you confirm the issue has disappeared ? If not, how can I reproduce it ?

Title MusicXML export may have bad staff positioning Font issue in MusicXML export

I cannot reproduce; it was probably fixed years ago.

However, after loading that file into a current build and exporting, I got an error importing into Finale Notepad - "XML error in file dusk.xml at line 63,816: An element with the identifier "P8-I68” must appear in the document. And after dismissing the error dialog, the file imports but most text has font / markup information embedded in it.

Btw, I get essentially the same error message importing the resulting XML file into MuseScore, but then it crashes.

To be clear:

1) load oroginal MSCX file into current 2.0 build
2) export as XML
3) open resulting XML file

Result: error message complaing about P8-I68, the crash if try to open anyhow.

The crash occurs in TimeSigMap::tickValues(int t, int* bar, int* beat, int* tick) const, the qFatal in line 142 is executed. Don't know why and don't know if this is related to the P8-I68 error.

The P8-I68 error is caused by a missing instrument definition in the drum part, while some notes still refer to it. Once again, don't know why.

Requires further investigation.

The embedded font / markup is #25193: [MusicXML Export] export formatted text as MusicXML.