Spacing issues when choosing a custom font for chord symbols with standard chord description file
A stem from this thread.
As quoted best from Marc, "...when choosing a non-standard third font for your chord symbols, too much space is left before the flat sign when using the default chord description file that was designed to work well with the default font."
Here is a link for a visual reference.
Comments
There is not much we can do I'm afraid... If you want to use another font than the default for chordnames, you will need to create a new chord description file and position the flat manually.
This is true. But something does seem wrong with the behavior here. There is quite a bit more space than I'd expect - it should at least come a little closer to working well than it does. Plus, I'm not understanding why the accidentals themselves are rendering with default font rather than the custom one. I thought I had set it up to prefer the font from the chosen font. Although in this case, that would be a mistake, because I'm betting Opus doesn't use standard Unicode flat and sharp signs. So I do want to take a look and see what is going on.
At the same time, you might want to take a look how to disallow the change of fonts for chordnames text style....
Disallow for the style? Why would I want to do that? I think people should be able to change fonts, or at least change font *size*. If some fonts resut in less than ideal spacing, that's fixable with a tweak to the chord description file. Or maybe I'm misunderstanding?
So far, what I am seeing is that for some fonts, I seem to get suspect values from the font metrics routines reporting the width of various characters. My weekend starts now, so I'll be able to investigate further.
If it makes any difference, I really like using the font Opus Chords Sans Condensed in 1.3, because it makes up for the inability to stack a chord on top of a bass note in a chord name (unless I just haven't found out how to do so yet). That font allows me not to have to spread out measures just to make long chord names fit on top of a measure with multiple chord changes. The music I work with does this a lot.
You can indeed get stacking of bass notes by editing the chord description file. See the lines that define "renderRoot" and "renderBass". I've never tried doing this in particular as I don't like that look - takes up too much space vertically and just isn't as familiar to me or more people accustomed to charts that do it more horizontally. But I'm thinking it would work to do a "push" at the beginning of renderRoot, a "pop" at the beginning of renderBass, followed by a m:0:8 (you'll have to experiment to find an appropriate value there to get the bass the right distance below) and then the bass note. Well, probably another set of push/pop/m commands to also get an underscore in there as a separator. You might try this, and if you have trouble figuring it out, maybe post a reply back to your thread in the forum, to avoid cluttering this issue with that discussion.
Anyhow, I think I have a handle on spacing issue itself. The issue is that MuseScore is trying to use the flat sign in the selected font, but the font you are using doesn't have a flat sign (or if it does, it is not in the standard Unicode location). Something within Qt appears to be realizing there is no flat sign and it is thus substituting the flat sign from some unknown other font, and that flat sign has a ton of space around it for some reason.
What I'd like to do is convince Qt to fall back to MScore1 for any characters it cannot find in the selected font. This would allow everything to "just work". I am not sure how to do this, though.
For now, though, the workaround is to edit the chords_std.xml and remove the two "sym" declarations that define "b" and "#". MuseScore will then symbol use the "b" and "#" characters fromt the font itself, and in the case of the Opus fonts, that measn you get flat and sharp signs.
I'm striking out so far. There is a Qt function QFontMetrics::inFont() that is supposed to tell you if a character is in the font, so in theory I can get MuseScore to use whatever flat sign I tell it to if a font lacks one of its own. Unfortunately, inFont() always tells me the font has the flat sign. I guess it's trying to outsmart me and using glyph substitution when answering the question. And the whole glyph substitution system looks frighteningly system dependent.
For now, I think I'll leave this alone - which means fonts without flat and sharps in the standard locations will look funny in chord symbols unless you edit the chord description file. Which you would very possibly have needed to do anyhow. It's still a viable alternative to return to the 1.3 approach of always using the built in flat and sharp, but this often creates ugly chord symbols for fonts that are actually well-behaved in terms of using Unicode code points. And I'd rather penalize the fonts that don't use Unicode code points than ones that do.