We are pleased to announce the release of SMuFL 1.18, a minor update to the specification that is focused on enriching the specification of font-specific metadata, as well as adding a small number of new characters to the standard.
Standard file system locations for font-specific metadata files are now defined in the specification. This is intended to solve a number of issues: firstly, to provide applications that want to consume SMuFL fonts with a reasonable way of determining whether or not a given font is SMuFL-compliant, via the presence of the metadata file; and secondly, to provide font designers with a standard location for these files to be installed, and updated along with new versions of the font.
Very simple installation scripts (based on Inno Setup for Windows, and Packages for Mac) are provided on GitHub for font developers to use as the basis of creating their own installers, and specify the appropriate locations for the font-specific metadata files to be installed.
The specification of the font-specific metadata file itself has also been enriched, with a new optionalGlyphs structure that should list all of the optional glyphs (i.e. those outside of the core, recommended glyphs, located in the range U+F400–U+FFFF) by name, code point, and (optionally) class. Steinberg’s in-development scoring application uses this structure as the canonical source of information about the optional glyphs present in a SMuFL-compliant font. Additionally, entries for glyphs in the sets structure should now contain the field alternateFor, which specifies the name of the core SMuFL glyph for which this glyph is an alternate.
Work is currently in progress on tools to help font developers ensure that their font-specific metadata files are well-formed: firstly, the use of a JSON Schema that will allow a variety of editing environments and tools to validate the syntax of a given metadata file; and secondly, a script that will check a syntactically-valid metadata file for common problems, such as misnamed glyphs, missing structures, and so on. When these tools are in a more complete state, a further announcement will be made.
Additions to the repertoire of recommended characters in this version include a new Metronome marks range, intended to disambiguate the (previous) dual purpose of the Individual notes range, making it clear which range should be used in text-based applications or text contexts within scoring applications for drawing notes in runs of text versus notes on a stave.
Four of the glyphs in the Clefs range, the triangular clefs between U+E06F and U+E072, have been renamed. This represents the first changes to canonical glyph names since version 1.0, and should be considered an exceptional circumstance based on the discovery of significant semantic errors in the description of the existing characters. Detailed information on this change can be found in this post to the SMuFL discussion list.
As always, full details of all of the changes since January’s SMuFL 1.12 release can be found in the version history, and you can also download the updated SMuFL 1.18 specification.
The Bravura font family has also been updated to version 1.18, and implements all of the changes in SMuFL 1.18, with the exception of the new recommendation that time signature digits should include side bearings to aid in character spacing for time signatures with multiple digits in the numerator and/or denominator. (It is expected that this recommendation will be followed in a future version of the font.)
There have been a number of minor revisions to Bravura since version 1.12 was released in January, including improvements to the appearance of key glyphs (thanks to Tucker Meyers for once again providing cleaner outlines for some ranges, including dynamics, ornaments, and keyboard techniques), fixes to the font-specific metadata file, and more. Complete details of the changes are found in the FONTLOG on GitHub.
You can download the updated Bravura family, including OTF, EOT, WOFF, and SVG versions of both Bravura and Bravura Text, from this web site, or browse the repository at GitHub.
Development of SMuFL will continue, as dictated by the needs of its community, and I encourage you to get involved in the ongoing discussion. If you are using SMuFL or Bravura for your project, I’d love to hear about it, so please get in touch to let me know what you’re working on.