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

[Michael Scott Cuthbert]

Agreed, and with what Daniel said.

I favor not being extremists on anything though.  If there is already a grace note glyph defined in Unicode and commonly provided in fonts, let's keep it, but not necessarily add anything additionally to SMuFL to support additional uses.  Similarly with 2/3 size or whatever clefs -- if they're already in common use keep them, but let's not add others.  The TAB clefs seem like a different deal since they are often resized vertically in an elegant (not simply stretched) manner without occupying more horizontal space.

Using different font sizes but keeping the same code points also helps show (for those applications that need it) that semantically these are the same figures at different sizes.


On May 30, 2013, at 11:36 AM, Joseph Berkovitz <[hidden email]>
 wrote:

> I also favor single occurrences of glyphs and letting the app do the resizing of cue, grace, etc.
>
> The only multiple code points that I really favor are those that achieve results which go beyond simple rescaling. Otherwise I fear we get into a very long and murky set of arguments about which scales should be present, and glyph scaling is surely something that any layout engine must expect to be doing a lot of.
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> President
>
> Noteflight LLC
> Boston, Mass.
> phone: [phone]
> www.noteflight.com
> "Your music, everywhere"
>
>
> On May 30, 2013, at 11:27 AM, "Daniel Spreadbury" <[hidden email]> wrote:
>
>> Dave wrote:
>>
>>> I'd have thought therefore that the objective for SMuFL would be to
>> enable
>>> you to write music (at a given size and style)  without having to change
>>
>>> fonts or font styles.    But it seems that you're telling me that this
>> is
>>> not the objective?
>>
>> At this point, I'm agnostic about whether or not it should be possible to
>> draw every possible musical symbol at any conceivable size without having
>> to use the font at more than one point size. My guess is that this is, in
>> its full generality, not a practical goal.
>>
>>> I am happy with the recommendation not to use precomposed glyphs.  But I
>>
>>> *would* like a grace note heads, grace-note-sized accidentals, and
>>> grace-note tail flags so I don't have to select the font at another size
>> to
>>> draw grace notes.
>>
>> You would also, then, presumably want all noteheads, all accidentals and
>> all note tails available at a third size for cue-sized notes, which are a
>> different size than grace notes? Cue notes are (per Gould, p.659) 75% the
>> size of normal notes, and grace notes are "slightly smaller" (Gould,
>> p.125). How much smaller than cue notes should grace notes be? You and I
>> may have different opinions about that!
>>
>> In any case, we're now talking about adding 82 x 2 glyphs to the standard
>> to duplicate all noteheads, all accidentals, and all tails at three sizes.
>>
>> And what about tremolo slashes? Do we need to provide them at three sizes?
>> What about articulations? What about other symbols that might be drawn on
>> stems, such as buzz rolls or sprechstimme crosses? What about jazz
>> articulations that are positioned to the left or right of notes? And on
>> and on.
>>
>> This is why I don't believe it is possible in general to provide the means
>> of drawing all conceivable music on a given staff size using separate
>> glyphs in a single font at a single size: the amount of duplication
>> required is really not insignificant.
>>
>> This seems to me a classic trade-off: duplicate hundreds of glyphs at two
>> smaller sizes in a font, and have the complexity of requiring calls to
>> separate code points for every possible symbol that could be drawn at
>> three sizes, versus having a consuming application using the font at up to
>> three sizes but use the same code points in each case.
>>
>> I remain deeply unconvinced about this, and my proposal is still to encode
>> glyphs only at their normal, i.e. full, size, and leave it up to consuming
>> applications to handle scaling.
>
>
> #############################################################
> 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]>