Category Archives: News

SMuFL 0.99 and Bravura 0.99 (1.0 Release Candidate) released

We are pleased to announce the release of version 0.99 of SMuFL and the corresponding version of Bravura. This is a release candidate for version 1.0; it is our expectation that, provided no serious errors or omissions are found in the next few days, this revision will be re-released as version 1.0 with no changes other than in version numbers.

A summary of the changes since SMuFL 0.9 follows:

JSON metadata

  • Modified the specification of the glyphsWithBBoxes structure in the font-specific JSON metadata such that the glyph’s name is the primary key, rather than the value of a name key, which makes it easier to consume this data.
  • Added an optional description key to the sets structure in the font-specific JSON metadata, to contain a human-readable description of a stylistic set.
  • Added a new fourth value to the type key for the sets structure, for large time signature digits intended for drawing outside the staff.
  • Added new graceNoteSlashSW and graceNoteSlashNE anchors to the stem-up 8th flag, and graceNoteSlashNW and graceNoteSlashSE anchors to the stem-down 8th flag, to aid in the registration of grace note slashes with unbeamed 8th notes.
  • Added new repeatOffset anchors to glyphs that require overlapping in order to be drawn correctly, such as the Multi-segment lines and Combining strokes for trills and mordents ranges, which allow correct registration of these glyphs when drawn independently rather than as a run of text (where the advance width of each glyph determines the degree of overlap).

Metrics and registration guidelines

  • Added a clarification in the glyph registration guidelines for fonts intended for use in scoring applications that parentheses glyphs may have negative side bearings to improve default kerning of these glyphs with the symbols they are intended to bracket.

Changes to recommended glyphs

  • Added 8 and 15 digits scaled correctly for positioning on G and F clefs.
  • Added a set of noteheads enclosed in large circles, used by some drummers.
  • Added an ornate X notehead contained within an ellipse.
  • Added Couperin’s pincé and tremblement appuyé ornaments.
  • Added a turned version of the thumb position string technique glyph.
  • Added a zero-width rectangle intended to enclose single percussion beaters inside a box.
  • Added strum direction arrows for guitar, and a stylistic alternate for the golpe glyph as used by Antonis Vounelakos.
  • Added an additional raised 7 digit for figured bass.
  • Added left- and right-pointing arrows for use in metric modulations.
  • Removed the ranges of glyphs for fingering charts for wind instruments.

New optional glyphs

  • Added recommended stylistic alternates for common time, cut time and + intended for use as large time signatures printed above the staff.
  • Added recommended ligatures for combinations of Johnston’s accidentals for just intonation with regular sharp and flat accidentals.

I would like to thank Nicolas Froment and Marc Sabatella from the MuseScore development team for their recent feedback. Joe Berkovitz of Noteflight has also provided very detailed and invaluable feedback on the use of the font-specific JSON metadata for Bravura, and has helped to identify a number of small problems that are addressed in version 0.99.

We are also pleased to announce that the ranges of glyphs in SMuFL are now browsable directly on this web site, in addition to being included in the specification PDF. Individual glyphs displayed on the site are taken from the corresponding version of Bravura, and individual glyphs are annotated with the origin point (to illustrate glyph registration), and any anchor points defined in the Bravura JSON metadata. We hope that this will prove to be a useful resource.

SMuFL 0.99 can be downloaded here, and Bravura 0.99 can be downloaded here.

If you believe you have found a significant error or omission in this version of SMuFL and/or Bravura, please sing out as soon as possible.

SMuFL 0.9 and Bravura 0.9 released

We are pleased to announce the release of SMuFL 0.9, which marks what we anticipate will be the final milestone on the way to a stable 1.0 release. As such, SMuFL 0.9 may be considered a release candidate for the final 1.0 release.

Since SMuFL 0.85, released in March, more than 200 new glyphs have been added, including four new ranges. A comprehensive review of LilyPond’s Emmentaler font has led to the addition of many new glyphs, and survey of important instrumentation handbooks by Ertuğrul Sevsay (Bärenreiter, 2005) and Karl Peinkofer & Fritz Tannigel (Schott, 1976) have led to the addition of a number of new percussion pictograms. New ranges for Kodàly hand signs, Simplified Music Notation and lyrics also provide a good number of new glyphs. As always, a complete list of the changes and new glyphs is available in the version history.

Our hope is that no further glyphs will be added to SMuFL before version 1.0. The deadline to request new glyphs passed at the end of March, and since then the focus has been on completing the work relating to producing guidelines for SMuFL-compliant fonts intended for use with text applications, and the development of a reference font embodying these guidelines.

A set of guidelines for SMuFL text fonts has been completed and can be found in the Notes for implementers section in the SMuFL 0.9 specification. The Bravura 0.9 distribution now includes Bravura Text, a reference font for text-based applications, in addition to the existing Bravura font, a reference font for scoring applications. The distribution also includes a usage guide for Bravura Text, describing how to insert Unicode characters from the font into applications on Windows and OS X, and providing details of specific features of the font, such as the use of ligatures to allow hundreds of symbols (including noteheads, accidentals, articulations, etc.) to be displayed at multiple vertical positions.

Bravura and Bravura Text are now supplied in Embedded OpenType (EOT) format, in addition to OpenType with PostScript outlines, WOFF and SVG.

There have also been significant developments in the richness of the JSON metadata supplied, both at the level of SMuFL itself and in font-specific metadata. The SMuFL metadata distribution now includes a new ranges.json file, which provides information about the glyph ranges as they appear in the SMuFL specification. The glyphnames.json file has been enhanced to include the human-readable description for each glyph in addition to its canonical camel case name.

The specification for font-specific metadata is significantly enriched, with new structures to help expose the repertoire of optional glyphs (in the range U+F400–U+FFFF) of a SMuFL-compliant font to applications, including descriptions of ligatures, stylistic alternates, and stylistic sets. Font-specific metadata may also include a bounding box for each glyph, which could in time help MakeMusic provide automatic Font Annotation (FAN) files for SMuFL-compliant fonts used in Finale.

Full details of all of the improvements in these metadata files is found in the Notes for implementers section within the SMuFL specification.

SMuFL 0.9 can be downloaded here, and Bravura 0.9 can be downloaded here.

With the release of SMuFL 0.9 there are no remaining known work items standing in the way of a stable 1.0 release. If you believe there is something significant that must be considered before SMuFL reaches version 1.0, please raise the issue with the community as soon as possible via the smufl-discuss mailing list.

SMuFL and MusicXML

Michael Good of MakeMusic has posted his summary of last week’s MusicXML community meeting, which took place at Musikmesse in Frankfurt. Fate conspired to prevent me from attending when two successive flights from London were cancelled, so my grateful thanks go to Michael for presenting my slides on SMuFL in my absence, and for taking notes on the issues raised.

It’s hard for me to respond to all of the issues that Michael noted down, as some of them seem to be statements or comments rather than questions, and I don’t have the benefit of the actual discussion to help frame a response. But I will respond to those items that I can, and offer a couple of further thoughts about the ways in which SMuFL might be integrated into MusicXML 4.0.

Font-dependent versus font-independent information

SMuFL itself defines the guidelines for font metrics (including a standard scale factor, namely that the height of the em square should equal the height of a five-line staff) and glyph registration (e.g. that a notehead should be positioned such that y=0 corresponds to the centre of the notehead if drawn on a staff line, etc.). SMuFL also defines the code point for each symbol, and provides a canonical name that can be used by software developers instead of the code point. (This data is made available in JSON format, which is easy for software applications to consume, and easy to convert to and from different structured formats.)

All of the above data is font-independent, i.e. it should be the same for all SMuFL-compliant fonts. This might mean that, were MusicXML’s positioning information relative to these SMuFL defaults (e.g. that a given default-y value should explicitly refer to the position of the glyph baseline, i.e. y=0), some of the mystery about how to interpret these values could be cleared up.

SMuFL also specifies a format for font-specific metadata, which it is recommended that font designers distribute along with their SMuFL-compliant fonts. This format includes values that are similar in scope to MusicXML’s appearance element (for line thicknesses, etc.), as well as per-glyph information about fine positioning details (such as exactly how a stem should connect to a notehead or a flag). Work is currently in progress for further metadata to be included in this format, such as basic glyph bounding box information (including cut-outs from bounding boxes to facilitate basic kerning, e.g. for accidentals), and more detailed information about the repertoire of glyphs in a given font, such as which stylistic alternates and ligatures are included (for those applications that cannot directly access e.g. OpenType glyph substitution features).

It makes sense to me that MusicXML should only concern itself with font-independent information. If a MusicXML file specifies the use of a SMuFL-compliant font in the music-font element, the consuming application has the choice of consuming the font-specific metadata directly itself: this does not need to be encoded in MusicXML at all.

However, if consuming applications could make assumptions about glyph registration and scale factors, as specified by SMuFL itself, it might simplify some of the issues concerning positioning and spacing.

SMuFL and text-based applications

Several questions were raised about whether SMuFL obviates the need for separate fonts designed to work in symbolic applications (e.g. Finale or Sibelius) or text-based applications (e.g. Word or InDesign).

The short answer is, unfortunately, no. This is not specifically a limitation of SMuFL itself, but rather a practical issue resulting from the different needs of symbolic and text-based applications. The fundamental problem is that in order to have a useful and consistent scale factor for glyphs in a symbolic font, it is also necessary to have a very large line height to accommodate very tall symbols (e.g. very short notes and rests), which means that inserting glyphs from such a symbolic font will greatly distort the line spacing of typical text fonts. (It’s not practical to set the font’s basic metrics such that the line height is appropriate for mixing with text fonts when glyphs extend significantly above or below that line height, because different applications, operating systems etc. handle such fonts inconsistently, typically resulting in issues such as glyphs being clipped incorrectly.)

Therefore separate fonts for symbolic applications and fonts for text-based applications are still required. As yet, SMuFL defines a complete set of guidelines for glyph registration and metrics for fonts intended for symbolic applications, but does not yet specify corresponding guidelines for fonts intended for text-based applications, though this is planned to be completed before SMuFL hits version 1.0, together with a reference font that follows these guidelines.

SMuFL does define code points for beams (both in the form of a MetTimes- or Opus Metronome-style preset glyphs that can be combined together, and in the form of generic control characters that can be used by font developers to do complex glyph substitutions to produce more dynamic combinations, if desired), and for things like cresc./dim. hairpins, but without the ability to specify the duration of such things.

SMuFL-compliant fonts are certainly suitable for combining notes and other markings in-line with text in things like tempo instructions, but it will depend on the consuming application and the specific font whether or not it is necessary to use a font designed for text-based applications or a symbolic font in these contexts.

Extending existing MusicXML elements and types

There are a number of areas where MusicXML already defines a wide repertoire of notations where SMuFL defines a larger number. This includes ornaments (the ornaments element), accidentals (the accidental-value type), accordion couplers (the accordion-registration element), percussion pictograms (the percussion element), among others.

One possibility for integration of SMuFL into MusicXML 4.0 would be to draw upon some of the extended repertoire for these notations in SMuFL and expand the MusicXML repertoire accordingly.

Enable access to any SMuFL glyph

One final possibility that had already occurred to me, and which was, I believe, discussed to some extent at the meeting, would be to create a specific element that could be used to declare any SMuFL glyph by its canonical name, rather than having to encode a Unicode code point as an escape sequence.

It is probably not a good idea to try to create a one-to-one mapping between semantic structures in MusicXML and ranges of glyphs or individual glyphs in SMuFL, even though every attempt has been made to provide some semantic information about each glyph included in SMuFL. But it might be useful to be able to refer to a particular SMuFL glyph by name in cases where presently an arbitrary Unicode code point might be used instead.

Discussing further ideas

Discussion about SMuFL itself and its repertoire of glyphs, the specification of its metadata formats and guidelines should be directed to the smufl-discuss mailing list. Discussion about how SMuFL might be integrated meaningfully with MusicXML should be directed to the MusicXML forum.

SMuFL 0.85 and Bravura 0.85 released

We are pleased to announce the release of SMuFL 0.85, another important milestone on the road towards a stable 1.0 release, which is targeted for the first half of this year.

SMuFL 0.85 is the first version to include the classes.json metadata file, which specifies useful groups of glyphs for consuming applications. Classes are entirely optional, so it is not required that a glyph should be in any class. Likewise, glyphs can be in multiple classes. Consuming applications can choose to use the classes metadata to help work out how to handle different glyphs within a SMuFL-compliant font.

There have also been a number of improvements to the classification of glyphs within ranges in this revision. For example, the Quartertone accidentals (24-EDO) and Other microtonal accidentals ranges have now been combined into a single Other accidentals range, such that each of the preceding ranges of accidentals represents a coherent system, and all of the remaining accidentals used on a more ad hoc basis are now grouped together. Similarly, the number of glyphs in the final Miscellaneous symbols range has been reduced by redistributing the percussion swish stem decoration and staff divide arrows to other groups.

New and expanded ranges of glyphs in this revision include the addition of a range for Kievian square notation (in response to a comparison between the repertoire of symbols in Emmentaler and those specified by SMuFL), further revisions to the plainchant ranges, and significant expansion of the Electronic music pictograms range.

As always, complete details of changes and additions are found in the version history.

We are also pleased to release an update to Bravura, bringing it to version 0.85 in correspondence with SMuFL 0.85. With this update, Bravura is now distributed as an SVG font and in WOFF (Web Open Font Format) in addition to OpenType format.

SMuFL 0.85 can be downloaded here, and Bravura 0.85 can be downloaded here.

With the release of classes.json, we have taken another important step towards achieving the outstanding areas of active implementation that are blocking a stable 1.0 release. The remaining two areas are as follows:

  • Development of metrics and glyph registration guidelines for SMuFL-compliant fonts intended for use in text-based applications; and
  • Development of a version of Bravura that implements these new guidelines.

The stable 1.0 release remains contingent on the completion of the above areas of work.

Don’t forget: if you are harbouring suggestions for new glyphs, please submit them before the end of March 2014 for consideration in the 1.0 release.

Finally, Daniel Spreadbury will be in attendance at the MusicXML Community Meeting taking place this Friday 14 March at Musikmesse Frankfurt to discuss the possible integration of SMuFL with MusicXML as part of the proposed MusicXML 4.0 development. If you are planning to attend, Daniel is looking forward to meeting you there.

SMuFL 0.8 and Bravura 0.8 released

We are pleased to announce the release of SMuFL 0.8, another step towards our goal of reaching a stable 1.0 release in the first half of this year.

Thanks to valuable feedback from the community following the release of SMuFL 0.7 last November, this revision enforces that neither canonical glyph names nor code points for recommended glyphs will change once SMuFL reaches its stable 1.0 release. As such, it would be very helpful if members of the community could review glyph names for existing glyphs so that any changes that are recommended can be considered and, if necessary, implemented in good time.

SMuFL 0.8 also expands the repertoire of glyphs in significant ways. New ranges include:

  • Renaissance lute tablature, covering French, Italian and German styles
  • Fingering diagrams for educational materials and method books for recorder, flute, oboe, clarinet, bassoon and saxophone
  • Ivan Wyschnegradsky’s system of 72-EDO accidentals

Existing ranges have also been extended, including additional coupler diagrams and techniques for accordion, further microtonal accidentals (from Penderecki, Busotti, Bosanquet and Tavener), separate noteheads for white mensural notation, and so on.

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 release an update to Bravura, the SMuFL reference font, bringing it in line with the changes in SMuFL version 0.8. In addition to implementing all of the new and changed glyphs in SMuFL 0.8, there have been minor changes to a number of glyphs throughout the whole font to address potential rendering problems reported by the Adobe FDK checkOutlines tool. This should improve the reliability of the appearance of the font in a variety of applications.

SMuFL 0.8 can be downloaded here, and Bravura 0.8 can be downloaded here.

As we continue on our path towards a stable 1.0 release, the following areas are still under active implementation:

  • Development of metrics and glyph registration guidelines for SMuFL-compliant fonts intended for use in text-based applications;
  • Development of a version of Bravura that implements these new guidelines;
  • Development of the classes.json metadata file defining useful groups of glyphs for use in consuming applications.

At the moment, the stable 1.0 release is contingent on the completion of the above areas of work. Of course it is still possible at this stage to add further glyphs to existing or new ranges: a reminder that if you are harbouring suggestions for new glyphs, please consider submitting them before the end of March 2014 for consideration in the 1.0 release.

Towards SMuFL 1.0

I started work on SMuFL almost exactly a year ago, though at the time I didn’t realise it. Steinberg’s in-development scoring application needs music fonts, so I started to build one. Having worked on music fonts for another scoring application for many years and been hamstrung by retaining compatibility with third-party fonts that originated in the 1980s, and hence not being able to properly use Unicode and OpenType features, I quickly decided to make a clean break with the past, and not design our new fonts to be Sonata-like.

As work progressed on designing the look of the font that would eventually come to be called Bravura, it became obvious that a new approach to organising the glyphs in the font would be needed. I shared my early thoughts on the standard with a handful of expert music engravers and editors in the following weeks, and it quickly became clear that more heads were better than one: this should really be a community effort, and it could conceivably provide a real, designed solution to the problem of using different fonts in different music software (rather than the imperfect de facto solution that had been in place since other font designers started copying Cleo Huggins’ mnemonic glyph layout for Sonata).

Progress to date

After announcing SMuFL at the Music Encoding Conference in Mainz in May of last year, it has been exciting to see the community start to take off. A few statistics:

  • There were around 800 recommended glyphs in the first public release (0.4) of SMuFL. The current version (0.7) defines more than 1850 recommended glyphs, and hundreds more recommended ligatures and stylistic alternates.
  • More than a dozen subject area experts around the world have contributed to the selection of glyphs to be included in SMuFL to date.
  • There have been more than 330 messages on the SMuFL mailing list to date, and the list has more than 70 subscribers.

SMuFL has also received support from software developers large and small. For example, the developers of MuseScore have already started work on integrating it, and it is expected to be a part of the forthcoming MuseScore 2.0 release. I have also been contacted by several other developers, who have expressed their intention to support SMuFL in their applications.

Our reference font, Bravura, has also been downloaded from our web site hundreds of times, and is already being used in the current versions of Rising Software’s ear training and music theory applications, Auralia and Musition, on both Windows/Mac and iOS.

If you are working on an implementation of SMuFL or are using Bravura in your software, please let me know, as I am very interested to track the progress of these projects.

SMuFL 0.8

As things stand, version 0.8 of SMuFL (and Bravura) currently includes the following changes since version 0.7:

  • Based on community feedback, added clarification that code points for glyphs may change until SMuFL reaches version 1.0, after which point existing code points will become immutable.
  • Glyphs in SMuFL encoded in the primary range of U+E000–U+F3FF are no longer considered “mandatory”, but rather they are “recommended”: in order to be considered SMuFL-compliant, a font need not implement every recommended glyph, just as a text font need not implement every Unicode code point in order to be considered Unicode-compliant. Fonts need only implement those glyphs that are appropriate for their intended use at the correct SMuFL code points in order to be considered SMuFL-compliant.
  • Changed guidelines for metrics of text-like glyphs (e.g. dynamics, D.C./D.S. markings in repeats) in fonts intended for use in scoring applications, such that it is recommended that the x-height of such glyphs is around 1 staff space (0.25 em).
  • Added Ivan Wyschnegradsky’s system of 72-EDO accidentals.
  • Added Britten’s curlew sign for a pause of an indeterminate length.
  • Added push/pull signs for accordion.
  • Added slashed sharp/flat accidentals used by John Tavener in his Byzantine-inspired choral works.
  • Added separate noteheads for white mensural notation.
  • Added quasi-random wiggly lines (wiggleRandom1wiggleRandom2wiggleRandom3wiggleRandom4) to multi-segment lines range.
  • Added flipped and large versions of constant circular motion (wiggleCircularConstantFlippedwiggleCircularConstantLargewiggleCircularConstantFlippedLarge) to multi-segment lines range.
  • Added combining top/middle/bottom segments for black and white rectangular note clusters.
  • Added 2, 3, 4 and 6-dot divisi indicators for measured tremolos (tremoloDivisiDots2tremoloDivisiDots3, etc.) to tremolos range.
  • Added clavichord bebung glyphs for 2, 3, and 4 finger movements (keyboardBebung2DotsAbovekeyboardBebung3DotsBelow, etc.) to the keyboard techniques range.
  • Added double-height parentheses and brackets (csymParensLeftTallcsymParensRightTallcsymBracketLeftTallcsymBracketRightTall) to the chord symbols range.
  • Added recommendation for stylistic alternates for time signature digits 0–9 suitable for use as large time signatures shown above/between staves (timeSig0Large through timeSig9Large).

Due to the nature of the additions, there are a substantial number of code point changes between SMuFL 0.7 and 0.8.

Next steps

The goal, then, is to release version 0.8, and then to reach version 1.0 as soon as possible, so that the code points can be stabilised and developers can implement support for SMuFL with confidence. Per recent discussion in the community, once SMuFL reaches version 1.0, neither code points nor canonical glyph names for recommended glyphs will change.

This means that if more glyphs remain to be added to a given range in future than unused code points remaining in that range, new non-contiguous ranges will have to be created elsewhere in the Private Use Area to accommodate these glyphs. (This is not really a problem, since ultimately the actual code point used for a given glyph is arbitrary, but for the sake of tidiness, if nothing else, it is appealing to group all generically similar glyphs together if possible.)

In my view, the two things that stand in the way of reaching version 1.0 are the following:

  • Implementing outstanding requests for glyphs to be included. To my knowledge, the only specific requests outstanding at present are from Mark Adler and Michael Good at MakeMusic, and SMuFL 0.8 will resolve those requests. There are a couple of non-specific outstanding issues (e.g. Maurizio Gavioli has expressed that perhaps there is more to be done in the area of Medieval and Renaissance notation, and Steven Horn has suggested that there may be more glyphs to add relating to lute notation and tablature), but otherwise at present there are no significant known omissions.
  • Creating glyph registration and metrics guidelines for fonts intended for use in text-based applications. To date I have focused on fonts intended for use in scoring applications, but I believe defining the guidelines for fonts intended for use in text-based applications should be completed (and a reference font produced) before SMuFL reaches version 1.0.

I am interested to hear from the community whether anything else should be added to this list.

Likewise, if anybody in the community is harbouring any requests for new glyphs or ranges of glyphs to be added, please do not delay in making those requests as soon as possible.

And, of course, if anybody in the community would like to volunteer to assist with the definition of the design guidelines for fonts intended for use in text-based applications, that help would be greatly appreciated by me.

My proposal is that I set a deadline (perhaps the end of March 2014, if that is not too soon) for the community to submit proposals for consideration for SMuFL 1.0, and then finalise the 1.0 release as soon as possible after that, though at the present time it’s difficult to estimate how long that might take without knowledge of what proposals I might receive.

Thanks once more to everybody in the community for their contributions to date. I am looking forward to reaching the milestone of a version 1.0 release.

SMuFL 0.7 and Bravura 0.7 released

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.

SMuFL 0.7 can be downloaded here, and Bravura 0.7 can be downloaded here.

SMuFL 0.6 and Bravura 0.3 released

Following on the release of SMuFL 0.5 and Bravura 0.2 at the beginning of July, we are pleased to announce the release of the next revision to the SMuFL standard, version 0.6, and a version of Bravura that is compliant with the new revision, version 0.3.

One of the key developments over the past few weeks has been discussion about guidelines for font metrics and standardised glyph registration for fonts intended for use in scoring applications. SMuFL 0.6 includes the latest version of these guidelines, with particular thanks to Joe Berkovitz and Emil Wojtacki for their detailed input into their development. Bravura 0.3 has been updated to match the new guidelines for glyph registration, and can be examined as a reference implementation.

The other most significant change to SMuFL has been a reorganisation of the glyphs representing ornaments. The former single range called ‘Ornaments’ has now been divided into four ranges (for common ornaments, less common ornaments, combining strokes for trills and mordents, and a range of precomposed trills and mordents using the strokes defined in the preceding range).

In reflection of the fact that it is impractical to define a canonical interpretation for each of the symbols used as ornaments in music of the 17th and 18th centuries, the descriptions in SMuFL for those beyond the ornaments generally considered standard and well-understood tend towards their visual attributes rather than their musical meaning; for example, a glyph that was described as a “forefall” in SMuFL 0.5 is now described as “double oblique straight lines, SW–NE” in SMuFL 0.6.

A small number of glyphs that were included in SMuFL 0.5 by virtue of having been included in the Opus font family (the default font family that ships with Sibelius) have been removed from SMuFL 0.6, in order that SMuFL might more closely map the symbols and strokes catalogued by Frederick Neumann in his authoritative book on baroque ornamentation.

For a complete list of the changes and additions in SMuFL 0.6, please consult the version history.

SMuFL 0.6 can be downloaded here, and Bravura 0.3 can be downloaded here.

SMuFL 0.5 and Bravura 0.2 released

Since the initial public releases of both SMuFL and Bravura at the Music Encoding Conference in Mainz at the end of May, a community of application developers, font designers and music engravers has burgeoned around the proposed standard, and there has been a great deal of very valuable discussion about what glyphs the standard should contain, how they should be organised, and what technical requirements should exist for fonts to be SMuFL-compliant.

In order to foster further discussion and as a waypoint in the development of the standard, Steinberg is today releasing SMuFL 0.5, together with Bravura 0.2, an updated version of the Bravura font that is compliant with SMuFL 0.5.

Thanks to the contributions of many members of the community too numerous to name here, SMuFL 0.5 has almost doubled in size in comparison to SMuFL 0.4, with the addition of more than 600 new glyphs and a number of new ranges. SMuFL 0.5 also includes an interim set of guidelines for font metrics and glyph registration for fonts intended for use in scoring applications, which should at this stage be considered work in progress and a starting point for further discussion.

SMuFL 0.5 can be downloaded here, and Bravura 0.2 can be downloaded here.