[MusicXML export] qt-rich-text html tags in exported text

I think there is an additional passage needed to reproduce the bug. If you start from scratch in 2.0 dynamics are exported correctly to xml.

The problem arises when you:
- load in 2.0 a 1.3 file with dynamics;
- export this file to xml in 2.0.
If you now load this in 1.3 all texts will have html tags.
It happens since the dynamic is treated as text.
Html tags appear for every (customized) text, for example <b> tags appear for bold text etc...

Try with the attachments: the mscz file is the file saved by version 1.3. After loading this in 2.0 and exporting to xml we obtain the attached xml file (Reunion_Example_2.xml). If you import "Reunion_Example_2.xml" in version 1.3 all texts will exhibit html tags.

ea0cfcc, Windows 8.1

For the dynamics the cause is that the version 1.3 dynamics are imported in 2.0 as subtype "other type" (0), which essentially means MuseScore doesn't know the type, only the text.

The MusicXML exporter normally uses the subtype, but for other type, the fallback is to use the text. This doesn't work well here as the text contains xml …

I am tempted to call this a MuseScore "1.3 import" issue, as the import loses the dynamics type.

Other types of text still to be investigated.

Does not occur anymore (at least for dynamics). Looks like it was fixed by commit 5363f93 ("fix #25231"), changed Dynamic::setDynamicType(const QString& tag).

See #25193: [MusicXML Export] export formatted text as MusicXML for other types of text.

I assume this issue can be closed.

Automatically closed -- issue fixed for 2 weeks with no activity.

This must be reopened as it is most definitely still present.

It does indeed not occur when you have a ff or pp by itself.

However, a combined dynamic (like sempre ff) does exhibit the problem.

See attached files.

This is hampering exchange of files for the OpenScore project. Ouverture 1812 for example exhibits this problem.

Note to self: do not try to upload files with spaces in the file name.
Files can be downloaded now

I don't see any problem with the dynamics in the XML file. The velocities are the same in both places.

As far as the 1812 overture is concerned, if there is an issue that could be due to the process I used to make the score.

I initially entered the score in version 2.0.3. When I was asked to separate the parts as per the Open Score standard I used version 2.1 and used a save as so I would have a complete backup if something went wrong. The score that I submitted says it was created in 2.1.

I don't know if this has any affect on the issue or not, but this background might help to track the problem.

There was another anomaly identified on MuseScore.com concerning this score that may or may not be related. Since I created the score under 2.0.3, I used the template that included the Contrabass having the 8vb bass clef. I did nothing to change this when I separated the parts. When it was first uploaded, it had a standard bass clef and all of the notes were written an octave higher as would be expected. This was changed (I believe by shoogle) and the current version on MuseScore.com does not have this issue.

Sorry, don't agree.

Yes, it opens correctly in MuseScore. Likely both the mscz file and the MusicXML.

Yes, it is (correctly) exported as other-dynamics.

But this other-dynamics contains non-standard stuff:

sempre <sym>dynamicForte</sym><sym>dynamicForte</sym>

The point is: there is non-standard stuff in the MusicXML file. That MuseScore understands it when reading it is not relevant, and not a proof of "not a bug".

And it is very relevant to the initial bug report title which is "Qt rich text tags in exported dynamics". That's exactly what we have here.

I never made a claim about velocities.

And yes, it all looks nice as long as you stay inside MuseScore 2.x.

The point is (and that doesn't seem to sink in): the MusicXML export is non-standard, and thus not usable. That's a bug in MuseScore, and has nothing to do with the 1812 edition. It's just that the 1812 edition MusicXML exports suffers from this MuseScore bug.

To further confirm the issue, I opened the XML file in Sibelius and Finale. Both can't read the sempre ff dynamic, so it gets dropped.

I think you are referencing to this (which seems more related):
https://github.com/musescore/musescore/commit/9924c96d
https://musescore.org/en/node/25193

But we may assume all we want that it is fixed. The fact is: it isn't.

Note that this is a specific problem, as my test file shows. If you only have "ff", then the export is correct. The problem only occcurs for combined dynamics such as "sempre ff"

I think the main problem is: what is the correct way to represent "sempre ff" in MusicXml encoding?
MuseScore simply exports the dynamic internal text as an "other-dynamics" element. It contains a <sym> element, which is MuseScore text standard, but it is not MusicXml text standard.
Therefore, when importing it to other notation softwares, it does not appear as intended.

Do you have examples of how such a dynamic is exported by Sibelius and Finale?

That's the crux of the matter: what is the correct way to represent it?

In my view, both Finale and Sibelius (both Dolet plugin and native export) handle this wrong.

Finale and Sibelius native split this in two different direction-type elements. The first with a "words" element (the sempre), the second with a dynamics element (the ff).

Dolet plugin in Sibelius exports one direction-type, with two words elements (sempre and ff), properly formatted (ff in bold italic).

This last choice is in my view more correct than the first one. This is a single dynamics statement, and therefore only one direction-type element should exist.
But it really should have two dynamics elements, of which the first would be an other-dynamics to hold the sempre.

However... While this is likely legal MusicXML, neither Finale nor Sibelius correctly import this.

So that leaves us with the pest or the cholera.

The simplest solution is to just replace the sym characters MuseScore exports with their normal textual variant. So just ff instead of twice the dynamicForte. That is lowest common denominator, can be understood by everything. But it doesn't look nice as you loose the special font for the ff.

So in short: there is no good solution to this.

I'm implementing a workaround in my MusicXML import to handle this. So it;s not that critical for me. but it might be for others.

I looked at the Music XML 3.0 standard and there is no standard for such modifications of dynamics such as "sempre ff." That leaves the question of whether attaching the modifications to the dynamic is the correct path to take in the first place. Looking closer at the sample in #2 leads me to agree that the current method needs to be re-examined.

XML is meant to port scores to other applications. Since I don't use other notation applications, I don't know if any of them would interpret MuseScore's version correctly. I guess the real question is, "Does the current method allow for porting scores to other programs?" Depending on the answer to the question, what needs to be done is obvious. If other programs correctly interpret it, there is no problem with it no matter how convoluted the XML line is. If other programs don't interpret it properly, then it needs to be fixed.

The quick answer is "no". You have no guarantee that other programs will interpret the MusicXML export correctly.
That's why I propose to export as just "words" "sempre ff". The formatting is not fine, that's true, but it has a better guarantee of exporting the correct semantics to other programs.
MusicXML is really a lowest common denominator. Anything fancy you want to export to other programs is likely to fail, and might even break import.

See the comment https://musescore.org/en/node/25164#comment-743186 and further. The issue is still actual.