[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
Grzegorz wrote:

> > I'm not sure how OpenType ligatures work. If a program is going to
> > see an mp ligature, for instance, as a separate code point, that
> > code point needs to be standardized, not left up to the font
> > designer's discretion.
>
> No code point will be left to the font designer's discretion. If I
> recall correctly, each of these additional code points for reaching
> ligated or otherwise combined glyphs directly will be part of the
> standard also.

No, that's not quite what I intend at present: all discretionary glyphs
(e.g. ligatures, stylistic alternates, etc.) will be encoded in a range
set aside for that specific purpose (my current working proposal is
U+F400–U+F8FF, i.e. the last 1280 code points in the Basic Multilingual
Plane), but the code points to be used by such discretionary glyphs are
not dictated beyond that. This is because different fonts might want to
implement different sets of alternates or ligatures in ways that we cannot
anticipate now.

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.

> > It seems similar to the convenience of having accent-staccato
> characters, which are in SMuFL 0.4 even though it's a combination of
> accent and staccato characters.
>
> If the multiple-letter dynamics ligatures in particular don't have
> such direct code points, it's because their ligation is pure
> aesthetics, not a technical requirement: in absence of any text
> shaping support the <mezzo, forte> sequence will display just fine,
> whereas the <accent, staccato above> sequence would not be formed
asexpected.

Yes, this is my feeling too, but I do take Michael's point that in this
case we are talking about "only" 20-something code points, rather than
hundreds. I will give this more thought.

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