[smufl-discuss] Re: Private use area?

[Michael Scott Cuthbert]

I’d say as someone whose main use for Smufl is to be able to encode some elements of musical symbols within a mainly text environment that having separate code points for clef changes would make it harder to parse musical meaning out of a text.  I do like the notion of being able to encode change-clefs as an opentype variant and I think that the suggestion of using the SmallCaps variant for it is a good one and better than having separate symbols.  I wouldn’t object however, to a tiny group of non-printing control symbols that suggests that the following symbols are to be rendered at cue size, “change” size, normal size — but I’m not sure if that’s really in SMuFL’s domain.

Thanks also for the clarification on the Private use area.  For the purposes of Mozart and other applications that need displaying control symbols, would symbols such as "SPEAKER WITH THREE SOUND WAVES (U+1F50A)” already in unicode suffice?  I wonder if we’d want symbols for “locked staff layout” “locked page layout” — or if the 🔒 ('LOCK' (U+1F512) ) and 🔓 (‘OPEN LOCK’) would suffice for encoding meaning. [those are terrible on the default Mac rendering — too hard to distinguish from each other]

Best,
Myke



On Apr 4, 2014, at 11:16, Grzegorz Rolek <[hidden email]> wrote:

>
> Emil B. Wojtacki wrote:
>
>> Well, I would say rather, that the "regular clef" is an "initial
>> variant" of a changing clef, i.e. a kind of flag, or reminder.
>
> Interesting point of view indeed. In somewhat more abstract terms then,
> the main function of a clef would be to reset, or change, pitch
> reference on the staff, with a special case of a reset from previously
> undefined state, the beginning of the staff.
>
>> However, it is possible for rendering devices to perform glyph
>> substitutions for Arabic, since typesetting relies on text strings. But
>> engraving does not. Scoring applications engrave music by outputting
>> single characters at different positions, not by outputting text strings
>> (except for textual annotations, like tempi or lyrics). This is a way of
>> thinking similar to manual engraving, like with steel punches in plates
>> from tin and lead. One punch, one character, one codepoint. And
>> contextual glyph variants cannot be substituted automatically by
>> rendering device (no text strings = no context), they must be picked
>> explicitly by an application.
>
> This is very reasonable. Having a more text-oriented background, I have
> to be reminded that SMuFL is more about 'font layout' as opposed to
> 'music encoding', after all. I'm curious then, how SMuFL for text
> settings will eventually shape out.
>
> Kind regards,
> Grzegorz Rolek
>
>
> #############################################################
> 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]>
>

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