I’m creating a lead sheet, and I normally try and include as much additional info as practical without cluttering the score, so sometimes I change clefs, add hits, etc. In this case, I’m using the “finale copyist” font that’s built into dorico, which has these lovely clefs, as shown in the first picture:
However, when I add a clef change in the middle of a score, it seems to grab the standard engraved clefs rather than the hand-drawn clefs from the finale copyist font, see below:
It ships with Dorico, as it is able to be freely distributed under the SIL Open Font License, but it was developed by MakeMusic and isn’t fully compatible with Dorico. When MM converted their fonts to be SMuFL compatible, they left out a lot of necessary glyphs.
In Finale you set this clef size in Document Options / Clefs / Reduction so Finale uses the same clef glyph and scales it down. Dorico more intelligently knows to use a smaller clef that was actually designed to be displayed at that size. If you look at the glyphs.xml file you’ll see Dorico is expecting a glyph for this at unicode location F472.
There was a thread about this recently, I encountered the same thing with Sebastian. I’m out of my depth on this subject but Daniel’s suggestion in the first reply did the trick for me. There are other workarounds mentioned there as well.
I think there are tools to build fonts; one could use them fill up the gaps to make a more complete “Finale Copyist” font. I have never done this, but I have heard it’s not too difficult.
Ah, just realized there is an undocumented split point with clefs, similar to the one with chord symbol suffix accidentals. Dorico will use the “standard” clef for scaling percentages 76% and up, and the small variant for 75% and below. If you switch to 76% (19/25) then Dorico will simply scale the larger clef and it will work for fonts that are missing the small clef variant.
Thanks all. Changing the scale factor is the easiest solution, so that’s what I’m going with for now. I did see that the small f and g clefs in the music symbols /glyphs window showed the wrong clefs, but didn’t quickly see how to change them, so the scale factor was the quicker fix.
Interstingly, when you select Finale Copyist as your font, I believe dorico uses the “finale copyist” for the text only and Petaluma for the actual notation. (at least, the clefs, key signatures, and time signatures look identical, and they’re different when I use that font in finale, so I assume that’s what’s happening). In which case, I think Dorico ought to select the correct small clefs when you use the Finale Copyist font too.
It’s not a bug, but it would be good if Dorico were able to handle this situation better than it does at present.
The glyphs beyond U+F400 in SMuFL fonts are considered “private” to that specific font family; they are optional, and although Bravura and Petaluma do happen to have some of the same optional glyphs, including these clef change glyphs, we don’t have a generalised mechanism for mapping between the optional glyphs in different SMuFL fonts. We need a bit more information in the font-specific metadata to be able to do this in a semantic way: we know that e.g. U+F472 is an alternate for U+E050, but we don’t know why that alternate exists. In the next version of SMuFL, we anticipate adding to the metadata to make it possible to identify what kind of alternate each optional glyph represents. That will then make it possible to provide a mapping between the optional glyphs in different fonts.
So any glyphs that Dorico looks for in the “private” F400+ range will always default to Bravura, since there’s not a mechanism for Dorico to know if the font actually contains those glyphs or not? And if the font does in fact contain an alternate glyph in that range, there’s not any way currently to confirm the location? Is that accurate?
Very nearly correct. The font-specific metadata files specify the locations of optional glyphs in the U+F400+ range, and specifies which of the recommended glyphs each optional glyph is an alternate for, but the problem is that it does not specify in what respect the optional glyph is an alternate: it could be an optical variant, or a different style used in a particular historical period or geographical location, or what-have-you. So knowing the existence of an optional glyph isn’t sufficient for Dorico to know that it should use that glyph in a specific circumstance. That is one key way in which the font-specific metadata needs to be enriched in future revisions of SMuFL.
Shouldn’t this work the other way around?
If your font recreates a specific engraving style, and glyphs for mid-system clefs are already properly sized, than in order to use them you need to set the Clef change scale factor to 3/4, and enlarge them manually in Music Symbols to 133%.
I think this is counterintuitive. If the glyph for a small clef is inherently smaller than a regular clef, it should simply display at 100% (the clef change scale factor 1).
It isn’t. The clef glyphs are the same size for the standard and small variants. The small variant is just optimized for display at smaller point sizes so the thin lines hold up better. Here are the standard and small variants of Bravura placed side by side at the same point size.
I don’t know what Dorico is doing when you are adding additional clefs to a single clef there, but if you just click back and forth you’ll see they are the same size.
They are the same size. It is very common with typography to have glyphs that are optimized for various display sizes. Often the glyphs are contained in entirely separate fonts like Minion Pro Regular, Minion Pro Caption, Minion Pro Display, etc. With Bravura there are optically sized glyphs for clefs intended for use at smaller sizes within the same font.
Dorico may be applying different processing or something when you add the glyph into its editor, or the editor may just be buggy (it’s certainly buggy with chord symbol editing), but that doesn’t change the fact that the glyphs are virtually the same size in the font itself.