I’m writing a big band score. The pianist has both hands in bass clef at some point. I notice the clef change to bass, and then back to treble are in a traditional music font even though everything else is Petaluma.
Bug?
What’s the best way to fix this for now?
It’s a 'known limitation" of the implementation. The clef change will always show Bravura, no matter what the chosen Music font.
There are two methods to fix it:
In the Music symbols Editor, change the F clef (small) character to the one in Petaluma. Also G clef (small) and C clef (small) if you need those.
In Engraving Options, change the size of the Clef Change font to 19/25ths. When the Change Clef size is larger than 75%, the active Music font character is used.
Maybe I don’t understand how to use the Music Symbols Editor (very likely). Changing the font isn’t doing anything. Any tips? I pick the font from the selector on the right, but nothing is happening. I tried clicking “add glyph” but no success.
Clearly I’m not doing it right…
Yep, I was using it wrong. Hahaha. Thanks!!!
Thanks for this workaround! Where is this change stored in order to be available in future projects or on other computers? In the project file only? I would consequently need to save project template?
Yes, the change is saved only in the project file in which you make the change. Depending on which route you take to achieve the result you’re looking for – either changing the music symbols or modifying Engraving Rules – you can save these changes as defaults for future projects, but only of course if you always want to use this other music font for all future projects.
Hi @dspreadbury ,
I wanted to follow up on this briefly to get a better understanding.
According to the SMUFL documentation and the corresponding json file, the alternate small clef for clef change is set to U+F472. If I take any font other than Bravura and change any symbol on any U+EXXX slot using various applications, the changes are immediately visible in Dorico. However, I can do anything to the U+F472 position and the clef will always be taken from the Bravura font. Interestingly, if I change U+F472 in Bravura.otf, I can also see the changed symbol immediately (but only for Bravura.otf, which I don’t really want to change for obvious reasons).
So the question is, why is U+F472 always taken from Bravura.otf, even though the font might have its own symbol for this slot? Of course, you could (and currently must) change the alternate symbols manually, but this has to be repeated every time you change fonts, which is a bit tedious.
(I am referring to gClefSmall / U+F472, but of course this could be applied to any other alternate symbol slot).
The glyphs in the range from U+F400 in SMuFL are font-specific, optional glyphs, not part of the core recommended glyphs in the specification. The code points used for characters from U+F400 upwards are different in each font, so while Bravura might have its small clefs at U+F472, another font could end up with those optional glyphs somewhere else entirely. One of the current weaknesses of the SMuFL font-specific metadata file is that it is not able to adequately categorise optional glyphs so that an application like Dorico can, for any font, know that not only is this particular glyph a variant for a clef, but that furthermore it is intended to be the small version used for a clef change.
The main focus of the next update to the SMuFL specification is to address this kind of shortcoming in the font-specific metadata files, after which time it will become possible, should font developers update their metadata files, for applications like Dorico to handle this differently.
@dspreadbury Thanks a lot for this detailed explanation. I am curious to see how SMUFL will develop further. Its introduction was a game changer and many extraordinarily good ideas have already been incorporated there!
