MuseScore 2.0.2 bottom.text from gets wrong position credit words from MusicXML.

(Forum discussion: 84056)
At the bottom line by means of credit words in MusicXML the next line has been defined:
{syntaxhighlighter SPEC}
Chart by Andy Dudnick andy@andydudnick.com

{/syntaxhighlighter}
According to the parameters the text should be shown at the bottom left of the page.

This is the OK in as well MuseScore 1.3 as in Sibelius as in Finale (all checked)
However it shows in MuseScore 2.0.2 it shows the text in middle of the page.

See attached results of 1.3 and 2.0.2 and attached MusicXML. This was the case with another >100 files as well.

I can only change footers character type, size, horizontal position not more then +/-5mm, left middle and right position do not have any effect whatsoever in MuseScore 2.0.2.

Even all parameters x , justify, font-size used in the syntax in MusicXML don't have any effect. I deleted all info left only the word content and it still decided it is a footer. Absolutely ridiculous.

The only info which decides where the credit words are displayed is the y distance. Everything between 800 (halfway the page ) and below or nothing y info at all is marked as footer. It ignores the x distance and anything else. Conclusion MuseScore 1.3 does a decent job. MuseScore 2.0 doesn't. Sorry to say so.

I've seen your result. but my experience with MuseScore is limited since I didn;t yet use it for anything else then applyïng corrections after importing MusicXML and exporting to .mscz.
So I choose Style -> Text -> then at the left I scroll down untill footer.
Then in the Text window it shows halfway the "Align" with "horizontal" 3 icons showing left, center and right lines.
Default it shows center. Choosing left or right and applying it doesn't change anything.
I see nothing about separating odd and even pages you're mentioning, so I think I'm using a wrong menu.

Additionally it seems you corrected the files wrt the displayed chords right?

OK, Succeeded now to correct the position. Thanks.
I'm still puzzled with the file you send me back.
First of all the foot text wasn't cluttered like the original with parts of the credit word syntax. That was the first issue I mentioned. So did you clean it? Or is this due a different page settings you might use during importing?

Secondly the translation of the second chord in measure 16 has been cleaned up from F/a/A into F/A. The is valid for the second chord in measure 22 which has been changed from Fm/eb/Eb into Fm/Eb.

This discussion was started in https://musescore.org/en/node/83996. So if you didn't edit anything, how come this chords show up correctly in your file? This file suffered from the same kind of problems wrt chords.

OK this clears up the text puzzle. So this remains an issue. But I showed you the representation of the chords as I expected them to show up, F/a/A and Fm/eb/Eb. This is a problem I mentioned in https://musescore.org/en/node/83996 with another file. The way MuseScore 2.0.2 now detects the chords let them show them this way. But your example was clean, which is very weird (not to say impossible unless you used a different MuseScore) if you didn't make the corrections yourself. So please verify it again.

Thanks for showing me. I must have been hallucinating, I guess I opened one where I did correct it myself. So I still need to build a filter to correct all my .xml files converted with PDFtoMusic Pro to be able to use 2.0.2 or stick to the old 1.3 MuseScore.

I think I first need to further investigate this problem, since it isn't only the bass note which causes a problem. Additionally Sibelius has another interpretation about how to handle it and Finale has again a different interpretation. So now we have 3 notation program makers with 3 different interpretations of MusicXML. I guess Michael Good the creator of MusicXML is the one who should comment. For me just building a filter for PDFtoMusic is the short cut since I'm already filtering their results anyway to correct many common problems due to the conversion.

Quote: that you should have explicit null text tags on those if you have incoporated information on alterations in your kind text to avoid duplicates.

This is the most important remark you write because PDFtoMusic Pro does duplicate everything in the text content. But Sibelius and MuseScore 1.3 don't duplicate this in the result however Finale does. I do use Sibelius for translating into .sib (for Avid Scorch) and MS 1.3 for translating into .mscz (for MS Songbook). So for me Finale was only used to double check some results, but they did duplicate all alterations, so they didn't do a good job imho. Some notation programs don't translate alterations and only very simple basic chords. Those need the kind text, to be able to translate the alterations. At least that is my impression and that from PDFtoMusic as well. So if you suggest (or better Michael) that you should use explicit null text if alterations are present PDFtoMusic Pro should reconcider what to do. It was their own decision, not asked for by me.
It took me a year to learn them (it was me who did ask them to implement all chord symbols) to translate all available BIAB chords, before everything did translate correctly. For me their results wrt. chords were perfect until now.

Now with MuseScore 2.0.2 I run into problems again. Since I anyway use an .xml filter to apply default corrections it is not difficult for me to solve it. I just did run a test, but it still did introduce a new mistake (a real mistake) from MuseScore 2.0.2., however I still use XP. I need to test it again in W10. (I've noticed another mistake from MuseScore 2.0.2 present in XP but not in W10 so I guess I need to test things first in W10. I guess that MuseScore isn't really eager to solve typical XP problems?).

OK, I will close this issue (the wrong position), since I learned to correct the position and I learned that MuseScore 2.0.2 does completely ignore the content of MusicXML about position whatsoever but follows its own rules about the footer text. (Which is also valid for title or composer)
It is a little bit different from MuseScore 1.3. where some control is possible. It is not unusual for a notation program to use its own formatting. Generally it seems to cause always many conflicts between the in MusicXML available text and the formats used.

Secondly some other issues were discussed which actually didn't belong here and which I will re-open.