[smufl-discuss] Re: MusicXML 3.0 symbols missing from SMuFL 0.4

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[smufl-discuss] Re: MusicXML 3.0 symbols missing from SMuFL 0.4

dspreadbury
Administrator
Emil wrote:

> Daniel Spreadbury:
> > So to represent 'mp', SMuFL says you would use U+E571 (m) and U+E750
(p),
> > and there could be an optional ligature uniE571_uniE570, with an
explicit
> > code point somewhere above U+F400, that an application could use
instead,
> > rather than 'mp' itself being encoded at an explicit code point
defined in
> > SMuFL.
>
> I think these ligatures could have codepoints in the range for dynamics
> (or, to be more precise: an additional subrange could be created).
> Similarly, in any range that ligated (composed) characters occur (like
> articulation or ornaments), providing a subrange for composed glyphs
> would be more convenient than one area above u+f400 for all kinds of
> symbols and more clear (both for application developers and end-users)
> than keeping different compound ornaments together with ornament
strokes.

I'd prefer to keep things simpler. If a glyph that we might consider a
ligature is really important and should be easy for a scoring application
to access, then it should be encoded in the mandatory area of the standard
(i.e. U+E000–U+F3FF). In the case of the dynamics, there is enough
precedent in existing music fonts to suggest that it would be useful to a
variety of consuming applications to have these dynamics encoded
explicitly in the mandatory area.

I did read your proposal that each range should be expanded to include
"private private" sub-range and ligated/alternate ranges, and I apologise
for not addressing that specifically before now, but my feeling is that we
should keep things as simple as possible. As things stand now, there are
mandatory glyphs and optional or discretionary glyphs, and to allow
provision for font and software vendors to extend the standard how they
see fit (e.g. if David Webber really wants to encode identical clefs at
multiple sizes for Mozart to use, etc.), then they have a range of 1280
code points set aside for just that purpose.

The forthcoming updated SMuFL documentation goes into more detail about
this, and hopefully the community will find my pragmatic proposal
satisfactory.

Daniel

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | 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]>