Very strange and unreadable chord font when opening a jazz score

• Jan 20, 2021 - 15:31
Reported version
P1 - High
S3 - Major

Seems to occur only with certain melodies

Attachment Size
OddMuseScoreChordFont.png 85.19 KB


.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.

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.

Status active needs info
Type Graphical (UI) Functional

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.

Workaround No Yes

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.

Status needs info active

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.

Status PR created active

I think I've experienced this issue myself and have reproduced it through actual use of MuseScore:

  1. In MuseScore 3.5.0, create a new score (using the default template).
  2. Set the Chord Symbols Appearance to….
  3. Enter chord symbols. Note that part of the chord symbols appear (correctly) in FreeSans.
  4. Save the file and open it in MuseScore 3.6.0. Choose Keep old style.
  5. Save the file again. Close and re-open it.
  6. The parts of the chord symbols which should have been in FreeSans now appear in the default chord symbols font.

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...)

Attachment Size
Broken.mscz 3.02 KB
Broken_3.6.mscz 4.39 KB
Reproducibility Randomly Always
Status active PR created

Thanks for the steps and files. My fix seems to work well with them. I'll test more later.

Status PR created fixed

Fixed in branch 3.x, commit 68badd8535

_fix #315897: unreadable chord symbols with custom description file


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._

Fix version