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

[Dave Keenan]

Hi Michael,

I am one of the designers of the Sagittal system and I agree with most of what you say. I was not previously aware of the mandatory/optional distinction you mention and, with you, I am horrified by the thought that all designers of SMUFL-compliant fonts should have to implement the full set of Sagittal symbols. Most of them are rarely used and many of the rarely-used ones are indeed very fussy. I am horrified because I totally agree that it is important to maintain a consistency of appearance across the font. In particular, the shafts, arcs and slanted bars of Sagittal symbols should be in the same weight and style as those making up the conventional sharp, flat and natural. So I agree one can't always just copy them from Bravura.

In fact we say, in the SMUFL document, that it is not necessary to implement the full set of Sagittals. This is in the implementation note after the first page of Sagittals. We point out that most microtonal notation can be done with the Spartans alone.

I believe that the problem lies, as you suggest, with the idea of "mandatory" versus "optional" glyphs. In fact I think the problem lies in the use of those two words to describe what seems to me to be purely a distinction between those glyphs which are stylistic variants or ligatures of other glyphs and have no standardized code point (and do not need any code point if certain OpenType features are used) and the other glyphs that have the standard appearance and have standardized code points.

Daniel,

May I suggest the terms "standard" versus "variant" glyphs for the above distinction, because it seems to me to be closely related to the distinction in the wider Unicode world between those glyphs which are representative of the character or grapheme being encoded and those which are considered variant glyphs for the same grapheme and so are not given a separate code point. Alternatively, "standard" and "nonstandard".

I agree with Michael that you might allow the font designer to decide which glyphs to include, and allow a font to be called "SMUFL-compliant" if it (a) uses the SMUFL code points for any SMUFL glyphs that it does include and (b) does not use any SMUFL code points for any non-SMUFL glyphs it may contain.

A font that includes all the standard glyphs, such as Bravura, might be called a "SMUFL-complete" font.

If you still decide that certain of the standard glyphs should be mandatory in any font that is described as "SMUFL-compliant", then yes, you should consider excluding those glyphs which are used extremely rarely, as Michael suggests, which means excluding most Sagittals. That is, excluding them from the new "mandatory" category, not excluding them from having a standard SMUFL code point.

I believe that SMUFL should continue to following the inclusive Unicode philosophy of preserving past antiquities as well as ensuring utility for the future, at least until we start to run short of code points. Therefore I think all Sagittals and Daseian etc. should remain in the SMUFL document and retain their standard code-points. But I think a font should be able to be called SMUFL compliant even when it isn't SMUFL complete, and that the decision about what to include should be left to the font designer.

I only recommend that the 26 up/down pairs of Spartan Sagittals (both single and multi-shaft) and the 5 Sagittal-compatibles be included in such a font (or in any mandatory set that may be specified by SMUFL), as these are by far the most commonly required Sagittals and they already have a significant following in microtonal circles.

Michael,

You wrote:

"The presence of 10 different systems indicates that Sagittal
notation is presently anything but standard."

I'm sorry we did not explain more clearly the purpose of the 10 different groups of Sagittals as listed in SMUFL. They are not 10 different notation systems. Sagittal is a single unified system of accidentals for notating pitch in every possible scale or tuning. And it is the only such universal system of microtonal accidentals that I am aware of. The 10 groups are in fact 10 different logical stopping points in the implementation of Sagittal, designed precisely because we knew it would be onerous for anyone to implement (or learn) the entire system. Each group builds on the previous groups to enable notation of ever more complex and obscure tunings with ever increasing precision. That is why each group, apart from the 3 basic groups I recommend above, is described as an "extension".

I've drawn a Venn diagram showing the relationship between these groups. As an attachment, it was too big for this forum, but you can see it here. http://www.sagittal.org/SagittalVennDiagram.gif

I believe Sagittal is a standard, because many microtonal experts contributed to its initial design over a period of four years, beginning twelve years ago. The first documentation and font were released in 2004. It was updated in 2006 with no change to any of the existing symbols (apart from improved readability and error corrections). Some new symbols were added at that time. It has remained stable ever since. It has a steadily increasing user base as far as we can tell from web searches and forum discussions.

Sagittal has been used by users of Sibelius, Finale and Lilypond and has been explicitly supported in Scala, MicroABC and Mus2. A "Sagittal Songbook" was recently published by Jacob Barton. It uses only the Spartan Sagittal accidentals.
http://www.lulu.com/shop/jacob-a-barton/the-sagittal-songbook/paperback/product-21286503.html

Thanks for your post.

Regards,
-- Dave

BTW Daniel, In footnote 6 on page 13, the link appears to be broken.



At 06:25 AM 21/12/2013, you wrote:

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]>

#############################################################

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]>