-
Problem Statement:
As additional features are added to the SMuFL specification with each successive version, the consequence is that we will see more SMuFL fonts "in-the-wild" which were created conf…
-
https://w3c.github.io/smufl/latest/specification/font-specific-metadata.html doesn’t say how it should be called. Is this arbitrary? Is there a recommendation?
-
U+E30E, *accSagittal35LargeDiesisUp* is upside down and looks exacly like U+E30F, *accSagittal35LargeDiesisDown* (As demonstrated in the current SMuFL specification):
![grafik](https://user-images.…
-
MusicXML 3.0 omits details of many alignment issues that are dependent on music fonts. An area where this omission is particularly harmful for interchange is in specifying how rests should be position…
-
Problem Statement:
With the vast number of glyphs available in SMuFL fonts, users need a method to easily find what they need. The Glyph Tables help with grouping like items, but users often still…
-
I am working on a SMuFL font and am using some old scores as references. One idea that I would like to implement in my own font is these teardrop shaped noteheads. As you can see in the reference phot…
-
This issue is similar to #219. Namely data integrity issues between OpenType data and the SMuFL JSON metadata.
In SMuFL the [`accidentalNatural`](https://github.com/w3c/smufl/blob/59c30fea57df39c29…
-
Some SMuFL fonts bring stylistic alternates for some glyphs like the recommended ones in Bravura: https://w3c.github.io/smufl/latest/tables/clefs.html
The problem is, that they share a code point wit…
-
How should the inclusion of glyphs like [flat] and [sharp] in runs of text be handled in CWMNX? Part name display is a case where this is needed.
In MusicXML one must switch between `` and `` to ma…
-
Apart from the tremolo element, MusicXML 3.0 does not have a way to indicate that a symbol should be associated with a stem. Instead, positioning attributes need to move the symbol into position on th…