What SMuFL metadata does Dorico actually use?

I think the title says it all. Daniel? Any insight you can give those of us developing fonts?

If you have a more specific question, I’m happy to answer it.

I’m fairly sure everyone understands that these may/will change over time, but certainly you’re sensitive to the fact that it is helpful information? I mean, the second to last time I wrote to you privately was because I thought I was stuck, whereas Dorico just wasn’t consuming a specific bit of the metadata, and the last was regarding the scripts, so I could simply stop worrying about it.

I don’t have time to write a treatise on every single detail of the SMuFL specification and how it fits in with Dorico’s current features, and I’m a bit miffed at the suggestion that I might, but if there is a specific question about a particular aspect of it, I am, as I say, happy to answer it.

I didn’t mean to offend, Daniel. Your customer support is legendary and I don’t expect you to cater to everyone’s requests, including mine. I also don’t expect you to be overly verbose in explaining very detail. I wasn’t asking that at all. I was merely wondering which data categories in the font metadata file does Dorico actually use and which are ignored? I understand that bounding box information, for example, is mostly ignored. I’ve had a hard time seeing if optical center properties are used, but it seems they aren’t. I’m just trying to understand so that I can anticipate what my font users should expect and what not to expect. Thanks for your time.

Dorico doesn’t use very much of the information in the font metadata file. It uses almost all of the engravingDefaults values, the exceptions being those that do not have corresponding options in Dorico itself (e.g. arrowShaftThickness, beamSpacing, beamThickness, etc.). It does not (and will very probably never) use the glyphBBoxes values, because it can calculate the bounding box values itself. It does not directly use the glyphsWithAlternates values, though we do have some specific hard-coded alternates (e.g. for clef changes), which you can find in the Engrave > Music Symbols dialog. It does use some of the data in glyphsWithAnchors, but only for certain types of characters, notably noteheads and accidentals. It does not currently use the data in ligatures, optionalGlyphs or sets at all.

I agree with Abraham. Please do not take the request in the wrong way, because that was certainly not the suggestion. I mentioned my previous contacts because I avoid writing directly precisely to safeguard your time, thinking that to be much more onerous, and yet I’ve bugged you before on this issue. I really hope you understand where I’m (we?) coming from. Although now I understand the reluctance to go into detail, and I’ll adjust accordingly. Just this previous post was very helpful, I feel. Thank you!

I very much appreciate your response, Daniel. That alone is very helpful information. So, would you mind confirming if the opticalCenter anchor point is currently or has plans for being used? I think it’s a wonderful feature that would be great to include, especially since the Engraving > Notation Options suggests this is possible for aligning dynamic text.

I’m excited to see Dorico grow into supporting more of the features. Maybe it won’t ever and I respect that since development time may be better used on more app-specific needs, but hopefully it will in time when creation of new notation features slows down and more time can be devoted to it.

Dorico doesn’t currently use the optical centre data for dynamics, but it is certainly planned.

That’s great to hear it’s planned! Thank you for the info!

In the latest metadata file version for Bravura I notice that dynamics have settings for “Optical Center”, does Dorico use these data?

No, not at present, though it’s planned. (That data has actually always been there.)

Ah OK, thanks for the clarification.
Then I can save myself the effort to edit them in my converted fonts.