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.