Unabled to add some SMuFL glyphs via a plugin

• Feb 11, 2021 - 23:16
Reported version
S3 - Major


Trying to utilize SMuFL glyphs and they seem to be missing. I can see them in lines 1316-1397 of MuseScore/src/libmscore/sym.cpp, e.g., "kahnStep",

this gets correct results.
var staffText = newElement(Element.STAFF_TEXT);
staffText.fontFace = "Bravura Text"
staffText.text = 'coda '; //line 853

this results with nothing visible.
var staffText = newElement(Element.STAFF_TEXT);
staffText.fontFace = "Bravura Text"
staffText.text = 'kahnStep '; //line 1853

thx, Matthew


In reply to by Marc Sabatella

yes, that one and the others in that class.

coda and clefs work.

Several of the kahn symbols result in nothing.

I checked with SMuFL/Spreadbury, he said they are part of 'Bravura' and "Bravura Text'.
MuseScore/src/libmscore/sym.cpp lines 1316-1397

I can work through all of them, but my gut says either I am coding it wrong, or the all the kahn glyphs are missing. But if I am coding it wrong, why would coda or various clefs work, and not these?


In reply to by Jojo-Schmitz

>>> .text = 'kahnStep ';
that is what I am doing in test6.qml, line 45.

I pulled this method from special characters.qml, which used gClef8vbOld.

special characters.qml made the reference to https://github.com/musescore/MuseScore/blob/6974f0c68e01c28124343205dc7…

then I realized this is where SMuFL symbols were defined, found the kahn symbols in the file.

kahnStep did not work. I found one directly above kahnBackChug, "indianDrumClef", not part of kahn symbols. It generated nothing, but I do not know that symbol is, so I went for coda and a few others without a problem.

Possible but not probable. Bravura hasn't changed in quite a while (well, it has rec ently, but that isn't yet part of MuseScore 3, only in the master branch so far, along with SMuFL 1.4 Beta). Not sure you should have it at all though, at least on Windows this built into MuseScore, not available externally, and having it available externally is know to cause issues. Not sure about MacOS though

In reply to by Jojo-Schmitz

The system font was overriding the font shipped with musescore.

all good now!

the last major technical notation hurdle, besides notating dance figures.

five years trying to navigate this problem: resurrect a 90-year old tap dance notation, create a font, write a W3 proposal for a previously unknown, but the oldest percussion instrument called "feet", defend the proposal, work out how these tap dance symbols should operate as music notation (originally they were on chalk boards as a spreadsheet); and now I can publish using my keyboard font to access the dance symbols as a viable notation ingest which are converted by a plugin to SMuFL Unicode PUA in Musescore.

thx JoJo.

In reply to by Jojo-Schmitz

as soon as I deleted the bravura font (circa 2015) from the mac os, it immediately worked. This would explain why some of the other glyphs I randomly picked had no graphics. Kahnotation was officially added to SMuFL in 2018.

But I was stumped how to get it to work in a practical way. My font does 't' for tap, 'l' for leap, 'h' for hop', etc. I could create scores and my font worked as pdf. But I could not publish on musescore because the text gets strange using option-shift-M to access 120 symbols. I tried to get google fonts to take it, nada.

Converting my font to Bravura by translating my font symbols to bravura's PUA was the trick.

Run the plugin, convert and upload; totally compliant with W3, SMuFL, and Musescore. And I have 100% IP control of my font to modify without going out for approval, it is still evolving in terms of ergonomics.

Well, as I said: Bravura handn't changed recently, but a 6 years old version is not really recent ;-)
I guess that was SMuFL 1.3 then, the first official w3c standard