Re: Proposal for new MusicXML 3.1 glyph element

I'm going to respectfully disagree with what I think is the consensus so
far, that once the glyph is defined in the <appearance> element, it is
applied globally. Instead, I agree with Sienna's position that "users
should be able to override this default on individual elements if desired".

To James Sutton's point about it being unexpected or confusing to use
different symbols in the same score, this is true if we are looking at a
score, but may be false in a few conditions, such as:
- Academic or reference works demonstrating the use of the different glyphs
- Software testing to see if a renderer is SMuFL and MusicXML compliant,
such as the Lilypond MusicXML test suite.

On Tue, Oct 4, 2016 at 4:48 AM, James Sutton <jsutton@dolphin-com.co.uk>
wrote:

> Seems good to me. It would be unexpected and confusing for a score to use
> different symbols for the same thing in different places
>
> James Sutton
> Dolphin Computing
> http://www.dolphin-com.co.uk
> http://www.seescore.co.uk <http://www.dolphin-com.co.uk>
>
>
>
> On 3 Oct 2016, at 21:43, Michael Good <mgood@makemusic.com> wrote:
>
> Forwarded with Daniel's approval as this was intended for the entire list…
>
> Begin forwarded message:
>
> *From: *"Daniel Spreadbury" <D.Spreadbury@steinberg.de>
> *Subject: **Re: Proposal for new MusicXML 3.1 glyph element*
> *Date: *October 3, 2016 at 12:54:21 PM PDT
> *To: *Michael Good <mgood@makemusic.com>
>
> Michael Good <mgood@makemusic.com> wrote on 03/10/2016 17:49:52:
>
> > What do you think? Does handling these glyphs in the appearance
> > element make sense? Or do you think we do need to handle each glyph
> > in a score individually? If there are examples of where different
> > types of glyphs for the same semantics are combined in a single
> > musical score, could you please reference them? Is there a different
> > way to approach these issues than the two solutions mentioned here?
>
> This sounds like an appropriately pragmatic approach to me. In my research
> on these specific glyphs as part of the SMuFL work, the idea that these
> glyphs would not be mixed within the same edition was certainly supported
> by the usage we found in actual publications. I think therefore that a good
> general approach to encoding different appearances for semantically
> identical symbols would be to use the <appearance> element.
>
> Daniel
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg,
> Germany
>
> Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net
>
> President: Andreas Stelling | Managing Director: Thomas Schöpe, Hirofumi
> Osawa
>
> Registration Court: Hamburg HRB 86534
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
>
>