fix #315897: unreadable chord symbols with custom description file #7370
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
53 tasks
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.
MarcSabatella
force-pushed
the
315897-custom-chord
branch
from
6bcf9f6
to
f385e1b
Compare
|
@MarcSabatella Could you please port the changes to the master |
29 tasks
MarcSabatella
added a commit
to MarcSabatella/MuseScore
that referenced
this pull request
Feb 17, 2021
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 in the 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 simply to unlaod 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.
But 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.