[smufl-discuss] Re: Rests

[dspreadbury]

Peter wrote:

> 1. As there are separate "restHBarLeft" (U+E4CE) and "restHBarRight"
> (U+E4CD) symbols for the text based applications, there might be a
> need for a separate middle part as well, so that the rest shapes of
> different width could be constructed.

That's a reasonable suggestion. I will make a note of it.

> 2. "restQuarterOld" (U+E4D0), isn't it rather stylistic alternate than
> a symbol for the main set?

This is a grey area, to be sure. In general we want to have as few
semantically equivalent glyphs encoded separately as possible, but where
there are very commonly-used variants for existing symbols, it seemed
useful to define them as recommended glyphs (i.e. with a dedicated code
point) so that consuming applications can easily use them.

> And by the way I didn't get a principle behind moving some
> self-important symbols to stylistic alternates (like
> "noteDoubleWholeAlt") and not doing it for others, less important
> (e.g., "gClef8vbOld").

It's ultimately a little bit arbitrary, and based either on my own gut
feel or the arguments put forward by the people in the community who
advocated for a particular symbol's inclusion. In each case there was some
thought behind it. Again, the general idea is that SMuFL isn't primarily
about encoding the semantics of every symbol used in music notation
(though it is a nice side-effect that we are able to pin down the meaning
of lots of symbols and provide them in a reasonably structured taxonomy
that will serve as a useful reference): it's really about defining a
sensible mapping for the different visual forms required by music
notation. So there is no hard and fast rule about whether or not a
semantically equivalent symbol should be encoded as a separate recommended
glyph or "demoted" to being a stylistic alternate for another glyph.

As I said above, the general principle is that the more common alternates
should be encoded as recommended glyphs, not because they are semantically
equivalent but because they are common. Equivalents that are less common
should be encoded as optional glyphs.

It's a balancing act, and I may not have got everything correct. At least
until we get to version 1.0, we can revisit some of these encoding
decisions if there are people in the community who feel strongly about
them (though that is itself no guarantee that anything will be changed at
this stage).

Daniel

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
Phone: [phone] | Fax: [phone] | www.steinberg.net
President / Managing Director: Andreas Stelling
Managing Director: Kazunori Kobayashi, Hiroshi Sasaki
Registration Court: Hamburg HRB 86534
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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