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.

10 thoughts on “Towards SMuFL 1.0

    1. smufl Post author

      I would be interested to know which specific symbols for lute tablature are required. Certainly it is within the scope of the project to include them, but I need some help in specifying what they should be, finding published sources, and so on. If you can contribute your expertise to help with this, please join the mailing list and talk directly with the community.

      Reply
      1. Anna Langley

        I would be happy to help, but I think those that have implemented the most used lute tablature programs probably have more to offer. As well as knowing the symbols, for the software to have an understanding of the conventions of the notation is important, if the result is to be both usable and readable. For example, that what appears to be a semiquaver in regular notation is typically counted as a crotchet in lute tablature, although this will vary. Sibelius and Finale both have the problem that all notes a crotchet or longer are displayed as a vertical line, which is frankly useless. Typically a line without a “flag” is a semibreve, with a breve having a flag sloping to the left.

        They are:
        Francesco Tribioli: developer of Fronimo http://www.theaterofmusic.com/fronimo/
        Wayne Cripps: developer of Tab (commonly known as “Wayne Tab”) http://www.cs.dartmouth.edu/~wbc/lute/AboutTab.html
        Christof Dalitz: developer of abctab2ps http://www.lautengesellschaft.de/cdmm/
        Musicks Handmade: django http://lute.musickshandmade.com/pages/django

        Reply
        1. smufl Post author

          I’ve already contacted a couple of these developers and have unfortunately received no response. I’m going to head off to the British Library later today to look at Diana Poulton’s book, which I imagine will help build my basic level of knowledge.

          Reply
    1. smufl Post author

      @Jude: Yes, those symbols are already included, along with a great many other systems of accidentals.

      Reply
  1. John Furey

    I notice the recommendations for using appoggiatura / acciaccatura in scoring systems suggest constructing the note rather than using precomposed glyphs. To that end, I looked for a small filled notehead in the font to aid this, particularly for beamed sets of appoggiatura where the defined glyphs wouldn’t work well. Obviously implementing a smallNotehead would have knock-on implications for accidentals as well…

    Have I managed to miss the definition of smallFilledNotehead or was it the intention to achieve the render of beamed appogiatura through scaling of standard noteheads etc…? If scaling is the preferred method is there any recommendation as to what scale factor should be used? I haven’t looked in detail at the slashes for acciaccatura but if scaling is the preferred method this would suggest that these are supplied relative to full sized notes rather than the more diminutive grace note size.

    Note that I writing this as a developer rather than someone who has any expertise in musical typography

    Reply
    1. smufl Post author

      @John: All glyphs are provided at a single size, so if you require symbols at a different size (e.g. for a clef change, or indeed for grace notes), then you should use a different point size to obtain the necessary result. Grace notes are typically around 60% the size of regular notes, though this does vary considerably.

      Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.