We are pleased to announce the release of SMuFL 0.7, which marks a significant step forwards in the specification of the standard.
A major focus of work has been to specify definitions for three metadata files, in JSON format, to make it easier for software developers to implement support for SMuFL in their applications.
The first, glyphnames.json, defines canonical names for each of the mandatory glyphs defined in SMuFL, together with their current code point; it is inevitable that some code points will change as the repertoire of glyphs in SMuFL is extended, so immutable names for glyphs will make it easier for developers to manage change as SMuFL itself and SMuFL-compliant fonts are further developed. An initial version of glyphnames.json is included in the distribution for SMuFL 0.7.
The second, classes.json, defines classes, or groups, of glyphs that should be treated in a consistent manner by consuming applications. For example, SMuFL defines hundreds of glyphs for different notehead designs, across a number of different ranges; the intention is that classes.json should list all of these glyphs (by name) in a single group, so that a consuming application may know which glyphs should be, say, presented to the user in a choice of notehead designs in a scoring application. Development of a full classes.json file describing all of the glyphs in SMuFL is ongoing, and feedback is welcomed from software developers about what kinds of classes of glyphs it would be useful to define.
The third JSON data file is for font-specific metadata, to capture information that cannot easily be obtained by programmatic examination of the font or individual glyphs within the font. This includes optional suggested defaults for common engraving values, such as line thicknesses and distances, that will produce an appearance consistent with the font designer’s original intention, and information about how individual glyphs should be registered and combined with other glyphs or primitives by scoring applications (for example, precisely how noteheads and flags should attach to stems drawn as primitives). The distribution for Bravura now contains a metadata file in this format for use by consuming applications.
These data formats have been developed in conjunction with Joe Berkovitz of Noteflight, to whom we owe a debt of gratitude.
Other major changes in SMuFL 0.7 include a significant expansion of the repertoire of glyphs for Medieval and Renaissance music, including daseian, mensural and plainchant notation. Thanks go to Michael Scott Cuthbert for his expert assistance in specifying the expanded ranges.
A number of other smaller changes and additions have been made in this revision of SMuFL in response to community feedback. Complete details can be found in the version history. As always, further feedback is welcomed.
We are also pleased to announce the release of Bravura 0.7, an OpenType font licensed under the SIL Open Font License, which implements all of the changes in SMuFL 0.7. (The last release of Bravura was version 0.3, accompanying SMuFL 0.6; we have decided to bump the version number of Bravura for this release, and intend for the version number of Bravura to match the version number of the version of SMuFL it implements in future.)
Bravura 0.7 includes hundreds of new glyphs, and also defines three OpenType stylistic sets: ss01 is for glyphs for use on small staves (i.e. different optical size); ss02 is for short up-stem flags designed to avoid augmentation dots; and ss03 includes straight flags. Developers who have already implemented support for earlier versions of Bravura should beware that version 0.7 also features significant changes in glyph registration, matching the updated guidelines provided in SMuFL 0.7.