Very strange and unreadable chord font when opening a jazz score
Reported version
3.6
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
Seems to occur only with certain melodies
| Attachment | Size |
|---|---|
| OddMuseScoreChordFont.png | 85.19 KB |
Fix version
3.6.2
Comments
(sample) score needed
.mscz file attached. However the strange chordname font appears in many files.
After selecting a correct chordname font from Format > Style > Chord symbols (eg. cchord_rb.xml) the correct chords are displayed. However, after saving and reopening the strange chord symbols return.
I see.
Workaround: Format > Style > Chord symbols, switch to Normal and back to Jazz
No, it does not, you're right those strangs symbols show up again after close/reopen
When I choose Format > Style > Chord symbols > Standard the chords are displayed correctly and saved correctly
However, if I go back to select the Format > Style > Chord symbols >Jazz option OR Format > Style > Chord symbols >custom option then incorrect display returns when saving and reopening.
It seems this file was created in a pre-3.6 version, then imported into 3.5 using the option to keep old styles, and then some had its chord symbol font forced to Edwin despite using the "Jazz" style. Normally that shouldn't be possible, even if you try specifying a foint other than MuseJazz for chord symbols when using the jazz style, it gets forced to MuseJazz internally, but for whatever reason, that isn't happening here.
Can you retrace your steps to remember how this happened, so we can try to reproduce these conditions from scratch?
BTW, the reason things don't work so well even if you try changing styles is that at this point, the contents of the chord description file has become hard-coded within the MSCX file. That also doesn't isn't normally the case but is probably a result of whatever actually happened.
Meanwhile, while I'd really like to now how the file got into this state, it's still the case that even as messed up as it currently is, it should be working, and I'm not sure why it isn't. So, we have enough info to investigate at least part of the problem, but not the cause.
Assuming the goal is to have the chords in MuseJazz, workaround to restore the file to a better condition is to set the chord symbol text style that way. This does survive save/reload.
I've managed to reproduce the conditions that lead to this, manually if not through actual use of MuseScore. So I don't have a complete understanding of what is going on, but I can say that yes, explicitly setting the chord symbol text style is at least a partial workaround. The error only occurs is the custom chord symbol style is trying to force the font to something other than the style default. It still won't necessarily be perfect - if the custom chord symbol style uses several different fonts or different sizes of a single font, there can still be mismatches in theory.
I'd still curious to know how this file got into this state, but I think I can fix the problem without knowing the answer. I'll just be more confident of the fix.
https://github.com/musescore/MuseScore/pull/7370
I think I've experienced this issue myself and have reproduced it through actual use of MuseScore:
If, instead of FreeSans, this had been with custom symbols from MuseJazz, it would result in the type of corruption seen by avronp.
I've attached the examples as saved by MuseScore 3.5.0 and 3.6.0.
(Edit: Oops! I started writing this before the PR was opened, so it's reset the status in the issue tracker...)
Thanks for the steps and files. My fix seems to work well with them. I'll test more later.
Another one https://musescore.org/en/node/316688
In reply to Another one https:/… by Jojo-Schmitz
And: https://musescore.org/en/node/316807
Fixed in branch 3.x, commit 68badd8535
_fix #315897: unreadable chord symbols with custom description file
Resolves: https://musescore.org/en/node/315897
There is a style setting to allow custom chord description files,
which is an advanced feautr eused by few today
but was the the standard/supported way of getting "jazz" chords
in older versions.
Scores using this option will have chord symbols rendering info
embedded within the score, in a ChordList tag.
Thus far, at the point where this tag was encountered,
the score's chord list was empty, and reading the chord list
worked as expected.
Now, however, the reading of the style defaults file for the score
results int he chord list having three "font" entries
before the actual chord list is read.
This results in the font references all being off,
meaning that the various special symbols used in chord symbols
get rendered as nonsense characters because they are in fonts
that do not support these special symbols.
Solution is unload the existing chord list
when we encounter a ChordList tag, before reading the list.
Previously there was a clear() call, but that's not enough,
we need to clear the fonts and other settings too.
Also, to be safe, I changed the initiation of of the font index
in ChordList::read() so that if there are any fonts
already present in the list, they are accounted for,
at least partially.
I also set the customChordList flag to make sure
we always write the chord lsit when it is custom,
and don't write it when not.
This was previously not being set when changing style
via the dialog - only on read.
As a result, a custom chord list didn't get written
until after save / load / save,
and was being written inappropriately after changing
back to a built-in (standard or jazz) style._
Automatically closed -- issue fixed for 2 weeks with no activity.