-
Notifications
You must be signed in to change notification settings - Fork 5
Open Questions
Proposal is to use OT stylistic alternates for individual symbols that need to be drawn with slightly different appearances on small staves.
Counter-proposal is to use a separate font, cf. "caption" fonts in OT text families.
Proposal is to have scoring applications scale the normal clef glyphs, and optionally also use stylistic alternates to choose clefs optimised for display at small sizes if the eventual visual size is sufficiently small.
Counter-proposal is to encode clefs for clef changes at explicit codepoints, scaled to two thirds the size of the normal clef glyphs (per Gould, p.7), on the grounds that the consuming application should not have to scale the glyph explicitly, but should instead simply be able to pull a different glyph out of the font.
Sonata, Petrucci, Opus, etc. all encode clefs once and then scale them: Emmentaler (Lilypond) and the font used by the Mozart program by contrast encode clef change glyphs separately.
If the counter-proposal is adopted, it should be extended to noteheads, accidentals and flags as well: two sets would be needed, one for cue notes and one for grace notes.
In order for musical symbols to look good when shown in line with regular text, the metrics of the font need to be broadly compatible with those of the text font being used. It is also the case that certain symbols when intended to be written in runs of text should have their appearance adapted for the purpose (e.g. notes may require a shorter stem in order to have a proportionally larger notehead, and the stem may need to be a little bolder to match the weight of the surrounding text, depending on the font used).
In general, the metrics required for a scoring application are incompatible with those required for text layout, given that the em square needs to match the height of a five-line staff and symbols are scaled according to that basic principle.
Proposal is that fonts should be explicit about whether they are intended for use in scoring applications or text-based applications, and have metrics suitable for their intended purpose: fonts for text-based applications should have "Text" appended to their name, while fonts for scoring applications need no specific identifier.
OpenType fonts include special features to provide alternative appearances for glyphs, by way of swashes, ligatures, stylistic alternates, fractions, lining vs. old style figures, etc.
Some of these special features could be useful in music fonts, such as using stylistic alternates for symbols designed for rendering at other sizes (though see the open question above about using stylistic alternates for this purpose versus a separate "caption" font), and ligatures for dynamics such as "mp" or "ff".
Fonts do not need to encode stylistic alternates, ligatures, swashes etc. at explicit codepoints because OpenType feature tables operate on glyph names rather than codepoints, but if a character is not encoded at an explicit codepoint, it cannot be accessed by APIs that are not aware of OpenType features, such as SVG or HTML5 Canvas.
Proposal is to encode any glyphs used as stylistic alternates, ligatures and swashes at explicit codepoints so that they can be accessed by any consuming application.
Should these glyphs be mapped to codepoints in the same ranges as the glyphs for which they are alternates or ligatures, or should they be mapped in a separate range set aside for alternates, ligatures, etc.?
To compose complete musical symbols from a mixture of glyphs and primitives (e.g. for an upstem unbeamed eighth note, glyphs are required for the notehead and the flag, and the stem should be drawn using a line primitive), consuming applications need to know how to position primitives and glyphs relative to each other.
Proposal is to use OpenType anchors to encode this information directly in the font. Anchors are used for e.g. specifying where diacritics should be positioned relative to letter forms.
However, there is concern that many APIs and platforms don't have access to these kinds of advanced OpenType features, so a counter-proposal is to create some kind of metadata file (perhaps using the lib.plist file designed for custom data in the UFO format, or by dumping out the contents of OpenType feature tables and post-processing them) that contains this information independently from the font, or at the least duplicates exactly the information stored in the font.