SMuFL creation

[OCTO]

Our member tisimst will perhaps answer to your questions. He is very experienced in FF. I personally would like to know more about creating music fonts in FF, since FF is really a great software, but I too experience many obstacles in creating fonts for Finale, Sibelius or smufl.

[benwiggy]

The font itself is one thing - and "merely" a question of getting the chars in the right places with the right names....!

However, how does one create a JSON metadata file for Dorico?

[tisimst]

If anyone hasn't read section 3.4 of the SMuFL gitbook, then I suggest you do so. It describes what the JSON metadata file should contain pretty clearly.
https://w3c.github.io/smufl/gitbook/spe ... adata.html

The trick is creating the JSON file with low overhead, of course. Most font editors have scripting capabilities, which makes doing this relatively simple. The procedure is fairly straightforward. I haven't published my script because it's not completely generic, but it is comprehensive to all SMuFL features (anchors, glyph alternates, stylistic sets). Right now, Dorico mostly only cares about the engraving defaults and bounding box sections, but I have been told that ONLY defining these won't be a good practice for long. Robert Piéchaud has a python script there already, but just know that there's a bunch of November & LilyPond-related code.

@benwiggy: You are correct. It "merely" takes a bunch of effort

@OCTO: Thankfully, SMuFL fonts seem to be more cross-platform compatible than those for other apps (sorry, Finale).

[benwiggy]

Robert Piéchaud has a python script there already,

Is the script on the Smufl site? I can't find it.

[tisimst]

Look in the scripts > fontforge folder at https://github.com/w3c/smufl/.

[composerjk]

…Dorico mostly only cares about the engraving defaults and bounding box sections,…

The optional glyphBBoxes bounding box section is primarily to provide data for Finale, per the footnote here: http://w3c.github.io/smufl/gitbook/spec ... html#fn_13

I would expect that Dorico would not need that section and hope that it pulls the bounding box from each glyph, itself, when needed.

[tisimst]

I would expect that Dorico would not need that section and hope that it pulls the bounding box from each glyph, itself, when needed.

Thanks for pointing out the info about the bounding boxes and Finale. I didn't realize that. I guess Daniel S. will have to chime in about whether or not Dorico uses the pre-computed bounding box values.

[Knut]

…Dorico mostly only cares about the engraving defaults and bounding box sections,…

The optional glyphBBoxes bounding box section is primarily to provide data for Finale, per the footnote here: http://w3c.github.io/smufl/gitbook/spec ... html#fn_13

I would expect that Dorico would not need that section and hope that it pulls the bounding box from each glyph, itself, when needed.

That's correct. Dorico makes use of the cutOut sections, as well as the various coordinates for stem connections, but does it's own analysis of the bounding boxes, and therefore does not need these coordinates.

[benwiggy]

Just to point out: to run the script I had to use:

fontforge -lang=py -script <script.py>

Where fontforge is a path to the binary inside the Application bundle's opt/bin folder!

[harpsi]

Hello,

I just found this:

https://usermanuals-staging-finalemusic ... o_Font.htm

From the page:"

Finale 2016 introduced FinaleMaestro, an updated and expanded Unicode-compliant version of the standard Maestro font used in default Finale documents. FinaleMaestro conforms to SMuFL version 1.0, a specification for standardized music font layouts that utilizes the Unicode Private Use Areas.

Is this really so? I guess FinaleMaestro should have been installed with FInale 25 then? If not, does anyone of you know where to get this?