A brief overview of digital music font design
Unlike designers of (digital) text fonts, music font designers historically were not restricted by standards and had great freedom, which has been both a blessing and a curse. While there was some common sense about what the kernel of music symbols should be (clefs, noteheads, accidentals, etc.), the actual position of characters in the font, their naming (though there was generally none provided), and the addition of rarer symbols beyond the basic set was left up to the designer’s imagination and to some specific requirements of the target music notation software.
Things are changing drastically with SMuFL, a font standardisation effort initiated by Daniel Spreadbury from Steinberg and now hosted at W3C in a welcome “joint venture” with MusicXML. This addresses issues of symbol position, naming and repertoire in a universal way, the idea being a world where fonts can be used in different scoring applications – just as everybody expects text fonts to be usable in any text processor or layout program. SMuFL is a great source of inspiration for the designer – surely one of its benefits – but it also imposes new constraints and requirements, and leads to a more demanding design workflow.
November 1.0 within the evolution of music fonts
In 1998 I designed November, an alternative music font, specifically for Finale. It had a distinctive “vivid” design and its repertoire of 330 characters, spread over two font files, ranging through historical periods spanning the Renaissance to the 20th century avant-garde, was considered large at that time (about twice as big as Sonata, for instance). Before SMuFL, the extension of November’s repertoire had often been considered, but, because Finale or Sibelius were using some ASCII-based map for music symbols (i.e. not Unicode, as the Unicode Music Symbols, a technological failure, had never been adopted), it would have most likely led to the multiplication of font files and more “character map anarchy”, as had occurred with, for example, Opus (Sibelius) or Maestro (Finale) ; consequently only small updates had been made over the years.
Then I regarded the emergence of SMuFL in 2013 as a great opportunity for November to make a bigger jump: one single font file with a greatly extended range of characters, wrapped in OpenType, and complying with a new standard.
That said, by switching to SMuFL, the font designer, who generally is a single individual, must be ready to face the temptation of adding more and more symbols, making the development process potentially much longer. And not only must the designer deal with thousands of vectors and points, but also to some extent he or she must turn into a programmer – but this won’t come as a surprise to the readers of this blog, who, as LilyPond users, have code lines in their blood, intimately mingled with the music itself. Python scripting, for instance, can be a great ally for generating the required metadata automatically; this was used extensively for the November 2.0 project. For SMuFL-scaled font projects, it is impractical to create those metadata manually, and, to make the design workflow even better, one can invent sophisticated tools, for instance to compare the font being crafted with the reference font, Bravura.
All of these considerations change the font development workflow deeply and, for fonts with over 1000 characters, you most likely want more automation in order to keep your hand and mind as free as possible.
November 2.0: a SMuFL-compliant font project
November 2.0, a multi-target commercial product released in February 2015, has now over 1200 characters, with 80% of them coming from the SMuFL specifications, and is the first commercially-released font to comply with SMuFL. Although it includes a much broader symbol range and many new features, the 2.0 version is still “in tune” with the design spirit of the font’s 1998 inception.
While the SMuFL standard itself has been quickly emerging (with Steinberg’s work-in-progress on a new scoring application in the background), existing notation software such as Finale, Sibelius or LilyPond follow at a somewhat slower pace.
At the present time, though this is likely forthcoming, no currently available notation software officially supports SMuFL in an open fashion (MuseScore seems to be SMuFL compliant, but sadly the choice of available font is by-design hard-wired). Therefore, in the short- to medium-term, a SMuFL-compliant font like November 2.0 must still be packaged specifically for each notation program. The SMuFL metadata, for instance, is currently not consumed at all by any of the major existing applications (including Finale, Sibelius, and LilyPond), and idiosyncratic component files must be supplied along with the font in order to ensure a smooth user experience.
November 2.0 is distributed as a single downloadable archive containing installers for Mac, Windows & Linux, targeting Finale, Sibelius, and of course LilyPond.
The default installation detects any versions of the aforementioned notation programs, and installs the right files at the right locations. November 2.0 also includes a comprehensive 200-page pdf documentation in English and German (French is in progress…)
Using November 2.0 in LilyPond
So how specifically does November 2.0 comply with LilyPond? In LilyPond we know that the font paradigm is similar to LaTeX: the Emmentaler font (and all its style variations: Feta, Parmesan, etc.) is constructed at compile time from meta font data, resulting in a single OpenType font family, mapped onto a specific character table. Comparing with Maestro or Opus, Emmentaler has had – for years – the advantage of being Unicode-based, addressing the problem of a unified font its own way. In order to use November 2.0 in LilyPond, I have followed the steps of Nathan Ho and Joram Berger. And, sharing with me the obsession for font variety and glyph “vivid” details, Abraham Lee has been of a great help, too.
So once November 2.0 is installed, switching is fairly easy as it only requires
at the beginning of the music file.
For a local switch to November 2.0, you may also use:
\novemberOn % ... music ... \novemberOff
within the music code.
Under the hood, we have some special ‘snippet’ component files making the use of November 2.0 within the LilyPond environment as smooth as possible. You generally don’t want to bother with these files, but, as an example and just for the sake of curiosity, here is how the stem tremolo is finely taken care of:
#(define-public (november-tremolo grob) (let* ((stem-grob (ly:grob-parent grob X)) (dura-log (ly:grob-property stem-grob 'duration-log)) (flag-count (ly:grob-property grob 'flag-count)) (dir (ly:grob-property stem-grob 'direction)) (adj (cond ((<= dura-log 0) -0.45) ((<= dura-log 2) (+ (* 0.3 flag-count) -0.3)) (else 0.5))) (vshift (if (> dir 0) (- 0 adj) adj)) (tremolo-name (string-append "tremolo" (number->string flag-count)))) (grob-interpret-markup grob (markup #:raise vshift #:novemberglyph tremolo-name))))
That said, while I could cover most of the notational aspects, there are still rare areas that are bit of a mystery to me, such as trill wiggles (wavy lines). Having looked into LilyPond’s code, they seem to be hard wired and I would advocate for LilyPond to provide easier (or, simply, possible) ways to overload those, through Scheme.
Meanwhile, the current compatibility of November 2.0 with LilyPond is fairly good. And more generally I hope that the claim of SMuFL-compliance for a rather popular music font, ranging across the major notation programs, can potentially help serve as an impetus for the developers of music notation software to support SMuFL more quickly and more comprehensively.
And I also believe that such a multi-target and SMuFL-compatible project may have the virtue of making the “vs.” reflex somehow irrelevant (Finale vs. Sibelius vs. LilyPond, free- vs. pay-ware, text- or GUI-based and so on).
In fact, whether we use music notation tools for our own purpose or under specific professional constraints, the access to style variety – as in text processing – should be left wide open, and graphic beauty should never be compromised.
- November 2.0 presentation PDF (in English)
- Klemm Music’s (publisher) November 2.0 page
- Interview with Robert Piéchaud on MakeMusic blog
Many thanks to Urs Liska, Abraham Lee, Nathan Ho and Joram Berger.