Double flat / double sharp not treated correctly in chord symbols
Ubuntu 14.04, GIT commit: 0156b04
1) enter chord symbol: Gbb7
Result: the "bb" displays as two separate flat signs rather than an actual double flat. For double sharp, "##" renders as two sharp signs; "x" renders as "x". No way to get an actual double flat or double sharp.
Furthermore, in German mode, the first flat or sharp currently renders as "es" or "is", which looks really bad - "Gesb7". And entering "Bbb7" does not work - because Bb is not recognized - but since Hbb turns into Bbb, you end up with a chord you can't easily edit.
The actual probloem here is in the parsing, not the rendering - typing Gbb is not recognzied as G double flat. It is recognized as Gb, with the second "b" actually getting applied to the 7. So it's actually represented incorrectly internally as well.
FWIW, this is a slight improvement over 1.3, where neither "bb" nor "##" were recognized at all.
Comments
part of the problem might be that Unicode fonts (available on Windows) do not (reliably) provide the glyphs for double sharp and double flat?
Well, that might be part of why it was never implemented, but in any case, the source of the problem is that we simply don't parse double flat and double sharp correctly when you type them using ordinary characters. That is, If you you type literally "Gbb7" (without the quotes), the parser sees that as "Gb", "b" "7". We simply don't have code to recognize the string "bb" as representing double flat.
This should be fixable, although I'm not sure what the expected behavior is for German with the note I would call B double flat.
I'm assuming this is all somewhat academic, and that we don't actually have a ton of people out there trying to type chord symbols with double flats or double sharps?
I've never seen one, but that doesn't mean anything ;-)
B -> H
Bb -> B(b)
Bbb -> Heses (not Bes!)
B# -> His
B## -> Hisis
OK, but given I am switching from "es" and "is" to "b" and "#" for ordinary flats and sharps, does that mean Hbb (actualy double flat sign) and Hx (actual double sharp sign)?
Hmm, I guess yes. Hbb is a better match to Heses than Bbb. And H## (or Hx) is correct too
https://github.com/musescore/MuseScore/pull/1483
What am I doing wrong? My font doesn't have the double accidentals:
NOT FOUND: 01
This is the German style.
What font are you trying to use? Not many fonts will have those symbols - they are part of the new SMuFL standard for music fonts. That is why the sym definitions I added explicitly sets the family to MScoreText, which does have these symbols. I did this soe MuseScore would use that font even if you change to a different font for chord symbols otherwise in your text style settings. It won't work to change those definitions to use some other arbitrary font unless it has those glyphs somewhere and you enter the correct codepoints in the sym declaration. Is that what you tried to do?
Not at all, I'm not doing anything special here. I downloaded nightly and ran it.
There is no MScoreText on my system. Typically these fonts are included in the executable, right?
I downloaded it from GIT, put it into Windows\Fonts, but I still see the little boxes instead of the ♭♭or ##.
Hmm, it works for me. Can anyone else verify?
I have found Windows has some sort of weird caching system where once you've installed a font, it's almost impossible to remove it complete it from your system completely. You should not have any version of that installed anywhere - MuseScore needs to be able to access the version built in to the executable. I suspect somehow an older version is still being found on your system.
Hmm, it works for me. Can anyone else verify?
I have found Windows has some sort of weird caching system where once you've installed a font, it's almost impossible to remove it complete it from your system completely. You should not have any version of that installed anywhere - MuseScore needs to be able to access the version built in to the executable. I suspect somehow an older version is still being found on your system.
Also, not that I think this would change anything, but does it start working if you change to standard chord spelling (as opposed to German)? If you are still having problems, can you post the score you are having problems with?
Hmm, one more thing - how are you *entering* the accidentals? What is supported is typing the literal strings "bb", "##", "x", and in German "eses", "ses", "sas", or "isis". Actually inserting the symbols from the F2 palette won't work, although I don't think it would produce that result either.
duplicate post
MuseScore Nightly, 30/11/2014. No MScoreText installed on the machine (well, I removed it and rebooted).
Create a new score, all standard, no German, no custom chords, just out of the box. Entered a note G and and A♭♭ chord. Shows as A followed by a box. As above.
So, is the correct font in the binary? Is the correct font at GIT? Can someone give me the correct font?
You aren't supposed to have *any* version of the font. As I said, the most likely cause is having some version of the font cached in Windows, and the solution would be to get rid of it. I am not enough of a Windows guru to know how to do it; I just know I fought this for months a couple of years ago myself.
To be clear - at no time should you *ever8 have MScore or MScoreText installed on your system on Windows. MuseScore *must* be able to to use the version that is compiled directly into the binary, and having any version installed will defeat that. And yes, the correct version of the font is compiled in - at least it is in my own self-compiles. I would assume that is true of the nightly builds as well, but I would like someone else to verify if they can get double flats & sharps to appear.
You aren't supposed to have *any* version of the font. As I said, the most likely cause is having some version of the font cached in Windows, and the solution would be to get rid of it. I am not enough of a Windows guru to know how to do it; I just know I fought this for months a couple of years ago myself.
To be clear - at no time should you *ever8 have MScore or MScoreText installed on your system on Windows. MuseScore *must* be able to to use the version that is compiled directly into the binary, and having any version installed will defeat that. And yes, the correct version of the font is compiled in - at least it is in my own self-compiles. I would assume that is true of the nightly builds as well, but I would like someone else to verify if they can get double flats & sharps to appear in a chord symbol (for example, by selecting the first rest of My First Score, pressing Ctrl_K, and typing "Abb7").
Well, I never had any font installed on my system - only for a brief period today after the problem had already happened.
Yes, I selected a note (G), pressed Ctrl-K and typed Abb.
Does the Abb show for you, I suppose it does.
Can you please try the Nightly?
I'm not on Windows; all will be different for me. We need another Windows user to test, please.
Just to be 100% clear: this is a different machine that the one you were using a few years to do font development, then? YThere is absolutely zero chancve you have leftovers from that?
Oh, one other thing you can try: see if you can enter the double flat/sharp symbol into a plain staff text using the F2 palette.
You're not on Windows? What are you using?
Yes, it's a different machine. Bought and setup in April 2013. However, there is 1.3 installed.
F2: double-flat works, double-sharp (x) works.
Placing an double-accidental in front of a note also works. The only thing that doesn't are the chords:
NOT FOUND: 01
I've installed FontForge for Windows (!) and looked at the font: 0xE263 and 0xE264 have the correct characters in them. The fact that I can place those characters in text and they work when placed on a note indicates to me, that the correct font is present in the executable.
Even if you hate the following comment:
If I install the "correct" font into Windows\Fonts temporarily the problem persists. The font from Windows\Fonts usually overrides the application supplied font (that's why its dangerous to have). So a program accessing those two characters should get them, since they **are** in the font.
So can someone please install the latest Windows Nightly and place a chord by typing "Abb".
The issue that I don't see double accidentals in chord symbols in plain normal English mode has sidetracked me from the issue that in "pure" German mode they look terrible:
NOT FOUND: 01
Please check the enclosed XML.
I'm on Linux (Ubuntu) mostly. I still have a Windows computer but it's not with me.
So, I think you have successfully ruled out the possibility of it being a font issue, but I'm out of ideas otherwise. Your score loads and displays fine for me, as do any scores I create myself.
Oh, yeah - if you do the "value=" thing, you probably want to remove the mag tag. Maybe the "family" attribute as well.
I'm about 50% committed to just going ahead and doing a native implementation of a "pure" German mode which would make that moot. But it wouldn't solve the problem with the font when using any other mode.
Well, "pure" German would be nice, then people don't have to fiddle with the XML. People could also switch from one to the other.
Playing around with the system, I made the big mistake to load the pure German custom style but forgot to click "German" below. That had terrible consequences.
Also, over in the other bug #40066: Use "b" and "#" rather than "es" and "Is" by default for German chords, when not in "pure" more, you would hopefully edit an F# as F# and not Fis.
So, in summary: A "one-click" pure German mode has many advantages.
I can confirm the issue of bb and ## not displaying correctly in chord symbols (not at all, actually) in the latest self-build version, c547bb7, nor in the corresponding nightly build, on Windows 7 (Enterprise, 64-bit)
OK, I'll look into why this doesn't work on Windows. Anyone able to test on Mac?
OK, I don't totally understand all the ins and outs here, but it has to do with font substitution & fallback - what happens if a specified font doesn't exist or doesn't have the requested glyph. Font substitution did good things for me, whereas I guess it doesn't for you. But the fact that I omitted a space in "MScore Text" didn't help :-). I'm guessing it might work for you if you add the space back.
However, now that I understand at least a little better, I am proposing removing the "family" attribute and relying on font substitution to find an appropriate glyph for you. If the font you have specified in your text style has that glyph, it should be chosen. Otherwise it might be a bit undeterministic where it gets that glyph from, but one way or another, you should hopefully get it. This is partly MuseScore's own mechanism, partly Qt's, and that's the part I don't totally understand. But on my Linux system at least, it seems to go to either Bravura or Bravura Text (not sure how it decides which, probably some attributes of the font), either of which works although the vertical position of the glyph differs depending on which is chosen.
I'm currently trying to get my Windows build working again. Meanwhile, could someone try this and see if it fixes it for them? Just remove the family="MScoreText" from the font tag for the double flat/sharp.
In any case, it does seem the 1.4 <mag< factor still makes sense, although if you are actually using a font for your chord symbol style that does have these glyphs and at these codepoints (very very few fonts will), you might need to tweak that.
Got my Windows build working again; good news / bad news.
Good news: adding the space works (family="MScore Text")
Bad news: removing the family attribute entirey does not, at least not for fonts that don't have the glyph. Apparently the font substitution / fallback on Windows works differently enough from Linux that I just can't rely on it.
So I'm inclined to just add the space and live with the fact this hard-codes the font for double flat and double sharp. Unless there is some programmatic trick someone knows I can use to force the substitution / fallback to work. I'll look into that, but IU don't cionsider this matter worth a ton of time.
Confirming the following:
When inserting the missing space into the name of the font "MScore Text" the double accidentals appear.
As for the "pure" German (just for the record, I know Marc is working on a native implementation):
Removing the <mag>1.4</mag> does make the "eses"/"isis" suffix a little smaller, perhaps by 30% (going from 140% back to 100% is taking about 30% off).
Thanks for the feedback. I've reimplemented things to use the Unicode code point rather than SMuFL for these accidentals, which should allow you to use any font that includes those glyphs (this includes FreeSerif). I've also added the glyphs to MuseJazz. Just trying to figure out the best way to generate TTF files to get kerning to work correctly on all supported systems - see http://dev-list.musescore.org/Kerning-td7579040.html.
Then after that and getting the lower case minor chord option working better, I'll push the change for "pure German" mode (making accidentals automatically switch to es/is/eses/isis when using German + lower case minor chords).
https://github.com/musescore/MuseScore/pull/1499
For now, I'm hoping that the same MuseJazz.ttf font will work correctly (with respect to general kerning; not related to chord symbols or double accidentals) on all supported systems. If this proves incorrect, we will go back to having a Linux/Windows version and a separate Mac version.
Fixed in 9b9aa19b63
Automatically closed -- issue fixed for 2 weeks with no activity.