[smufl-discuss] Glyph removal requests and reconsidering mandatory glyphs

[Good, Michael]

Hi Daniel,

Drawing a dividing line between standard and idiosyncratic notation is a
challenge in standardization efforts like SMuFL. SMuFL needs to be
powerful enough to support a wide range of music, but if it tries to
support every piece of music ever written, the added complexity comes at a
cost for font developers, software developers, and application users. Mark
Adler and I admire how you have balanced these tradeoffs so far.

At the moment, though, we think SMuFL 0.7 leans a little too much towards
the inclusive and idiosyncratic side. Take the addition of Daseian
notation, a term I first heard of when reading the SMuFL 0.7 spec. A quick
look at Wikipedia perhaps explains why: while it was used in two
9th-century sources, "this notation was not widely used in practical
sources", with neumes being used instead. These glyphs therefore seem to
be of extremely low practical value, and the characters involved are
rather fussy to create in your own font. These don't seem to belong in a
standard music font layout; this is a notation style that has failed to
catch on for some 1200 years.

Another example is Sagittal notation. There are now 20 pages of Sagittal
glyphs in SMuFL 0.7 covering 10 different notation systems. These
characters are also often quite fussy and complex for font designers to
create. The presence of 10 different systems indicates that Sagittal
notation is presently anything but standard. The presence of so many
complex, infrequently used symbols as mandatory glyphs seems an
unnecessary barrier to entry for SMuFL font and software developers. We
suggest that these be removed as well.

The other range that seems unnecessary are the combining strokes for
trills and mordents. Is there anything these characters offer that is 1)
used in music repertoire and 2) not already available with the
pre-composed characters already in SMuFL? Those who really want them could
use the existing Unicode mappings. The documentation would then have to
call SMuFL a "near-superset" of Unicode Musical Symbols, but that's OK.
The problem here isn't the complexity of the symbols, but the confusion
caused by including impractical choices in a new standard.

Even some of the optional characters seem questionable for a standard
layout. Most of the clef ligatures in particular seem obscure enough to
not warrant inclusion, even as optional glyphs.

Sometimes I've heard arguments along the lines that added characters
aren't a barrier to entry for font developers because you can always use
Bravura's glyphs if you don't want to create your own. That may hold true
for some developers. For most I think it fails on aesthetic, legal, and
business grounds. The aesthetic issue is maintaining a consistency of
appearance across the font. The legal and business grounds would involve
Steinberg providing indemnification against copyright claims for Bravura
users, which seems unlikely.

Maybe the larger issue is SMuFL's concept of mandatory and optional
glyphs. If you're creating a handwritten font for contemporary music, what
is the point of including neumes in your font? Neumes are an important
part of SMuFL, but for many fonts there is no customer value in supporting
them.

Currently optional glyphs are limited to things like ligatures and
stylistic alternates. It seems that the range of mandatory glyphs should
be scaled way back, or perhaps dropped altogether. Text font developers
usually don't implement every single Unicode character, yet their fonts
are still Unicode-compliant. Market demand will correct the fonts that go
too far in dropping characters, especially with Bravura setting a high bar
for inclusiveness.

Thank you as always for your consideration of these requests. I will be
out of the office next week for the holidays but will still have some
email access.

Best regards,

Michael Good
VP of Research and Development
MakeMusic, Inc.



#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>