Consider how to handle "on-staff" and "off-staff" use cases for fonts for text-based applications

[dspreadbury]

At the moment, Bravura Text is optimised for "on-staff" use, i.e. it uses a staff height of 0.8 em, designed to roughly align with the caps height of a typical text font, and all of the symbols that are typically drawn on the stave (noteheads, stems, flags, accidentals, etc.) are all scaled accordingly. They are also drawn as if on the middle staff line, and are then raised and lowered using ligatures with the staffPosRaise/Lower control characters.

As Dave Keenan points out, this is less than useful if you just want to show a specific symbol in a specific place scaled accordingly to the surrounding text: you have not only to use a ligature to move the symbol to the baseline, but also to change the point size. This is all a bit harder than it should be.

To resolve this, perhaps we need two separate text-flavoured versions of Bravura, one with all of the fancy positioning stuff, and one with all of the symbols scaled such that they are the right size at 0.8 em.

[mscuthbert]

I very much like the latter, and I think that's more of what I was going for in the initial suggestion. My sense is that we'll need to divide the symbols into collections that are likely to be used together so that glyphs that scale together are approximately in the right proportion. Mordents should definitely be bigger in relationship to quarter notes than they would be in a musical score, but in text, a quarter note and a sixteenth note should look proper next to each other and a mordent, inverse mordent, turn, etc. should all look correct when set next to each other.

If you'd like we could create a markup of the SMuFL specification document to try to place symbols into groupings that should scale together. Maybe as a shared document?

[dspreadbury]

Since opening this issue some years ago, my views on this issue have changed quite a bit.

When we started specifying SMuFL back in 2013 it seemed that there was a lot of use of and interest in fonts like the Bach musicological font, and so it was deemed an important goal of the project to make it possible to create fonts that can type relatively sophisticated music examples directly in the font.

However, given the inexorable rise of better and more accessible tools for producing music examples without the need for an expensive music notation application on the desktop (e.g. Lilypond, MuseScore, Vexflow, Verovio, Flat, Noteflight, etc. etc. etc.), there's much less inherent value in such fonts – and several of these provide flexible and powerful ways to include music examples inline in text. In printed documents it's simple to do by way of graphics or embedded mark-up (in the case of e.g. MusiTeX). On the web it's simple to do by way of graphics or embedded documents (using Verovio, Vexflow, etc. etc.).

The much more common and pressing need is to make it easy to include arbitrary individual musical symbols in the run of text, which is still inconvenient to do using these other solutions.

Therefore, my proposal now is that we turn the specification of SMuFL fonts for text-based applications completely on its head, eliminating all of the fancy glyph positioning and use of ligatures found in fonts like Bravura Text in favour of instead forming recommendations for how to alter the size and registration of glyphs such that they will be positioned and sized appropriately for inclusion in a run of text.

What is the community's view on this issue?