[smufl-discuss] Re: Glyph Registration and Graphical Metadata

[dspreadbury]

Dave wrote:

> Unicode has lots of precedent for this.   Consider the letter 's' in
middle
> English.   In the middle of a word it was tall (mistaken by some for an
f,
> but it didn't have the cross bar) but at the end of a word it was drawn
like
> a modern s.   They're different styles of 's' but in Unicode these are
not
> put at the same code point:  they're  U+017F and U+0073 respectively.
[They
> were also in different boxes in the type setter's font.]

I can't speak to the actual evolution of Unicode, but I think at least the
possibility exists that this is a function of the fact that the font
technology to provide things like ligatures, swashes and so on without
requiring separate code points was not available when the basic Unicode
mapping was done. But, either way, this is indeed how Unicode handles the
two forms of lower case "s".

> Just as the two forms of 's' have well-defined different usages in the
same
> text, the two forms of a clef have well defined usages in the same piece
of
> music.   And it is in exactly the same spirit of Unicode that they
should
> both be there, at different code points.

Well... I don't agree with this. I think we will have to find a way to put
this particular issue to a vote so that we can establish consensus.

> > For this reason it now occurs to me to object to having codepoints for
> > grace notes in the PUA range of SMuFL. They are already in Perry
> > Roland's spec at U+1D194~5, and they're only there because of the
> > legacy Sonata character set. (Notice there are no characters for
> > stem-down grace notes, etc.)
>
> I had.  And, unless I've missed them,  there are no characters for
> accidentals on grace notes.   I believe they should be included.  [I'd
be
> very happy to *exclude* a whole host of things like upside-down and
mirrored
> clefs, but I guess they're there because somebody wants them, so I'm not

> shouting about it.]

SMuFL is explicitly designed to be a superset of the Unicode Musical
Symbols range, so those grace note glyphs are included, even though I
believe I have written (and if I have not, I will) in the implementation
notes section on that page of the document that scoring applications
should not use those precomposed glyphs to draw grace notes any more than
they should use precomposed glyphs to draw any other kinds of notes.

> All of this depends on whether you are just collecting pictures of
musical
> symbols or defining a *font*  (originally a collection of wooden trays
> holding the movable type required to write everything in the given
style)
> whose purpose is to facilitate writing music.   I thought the objective
was
> the latter.   (And I don't regard 'Sibelius doesn't do it like that' as
a
> definitive argument.)

And I don't regard "Mozart does it like that" as a definitive
counter-argument either :^)

Daniel

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
Phone: [phone] | Fax: [phone] | www.steinberg.net
Managing Director: Andreas Stelling, Kazunori Kobayashi
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]>