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

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

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

dspreadbury
Administrator
Dave wrote:

> But
>
> (a) The PUA runs from U+E000 to U+F8FF  (if we consider the BMP only -
there
> are lots more elsewhere) which, if my sums are right, is 2034 points
(and
> so 164 is only about 7% of them).     This is luxuriously spacious
compared
> with what I'm used to with symbol fonts.
>
> (b) They're very quick for font designers to produce - just copy the
main
> one and change size to 75% or whatever.  they don't require much in the
way
> of extra design.

The fact that there are lots of empty slots to fill up isn't a valid
reason either way, in my opinion.

Perhaps I'm wrong, but it seems you consider grace notes and cue notes to
have very different requirements, and that grace notes can only ever
reasonably use a tiny subset of musical symbols (basically just black
noteheads, flags, and accidentals), but I think that's a rather limiting
definition. It seems to me you have chosen a fairly arbitrary selection of
symbols (a couple of notehead designs rather than all of them, some
accidentals rather than all of them, flags, etc.) and decided to make them
available at a different size for grace notes, even though a composer or
publisher may choose to include practically any symbol in a run of grace
notes.

If we're going to go down the road you want us to go down, we must
duplicate a huge proportion of the symbols encoded in SMuFL at *three*
additional sizes (since you rightly point out that you can also have
cue-sized grace notes, so there are four sizes in total: full, grace, cue,
cue grace). As we add more accidentals, more notehead shapes, more tails,
more symbols that attach to stems, etc., we must add four glyphs for every
new symbol we add, and all this to avoid drawing symbols at multiple font
sizes.

This seems like a very poor trade-off indeed to me.

> I'd also like a different set of accidentals designed to align with
text.
> (% more glyphs).

I think we have built a consensus around the need to have a separate font
designed for mixing musical symbols with regular text. So you can use the
same codepoints to get the character, but a different font. This does seem
to be the most elegant solution to the problem of incompatible metrics
etc. that has yet been proposed.

> > And what about tremolo slashes? Do we need to provide them at three
sizes?
>
> Not for me:  like the stems, I use line-drawing to produce them.   I was

> wondering why you included them given the recommendations to draw other
> straight line objects (eg stems and bar lines).

They're included because they are part of the Unicode Musical Symbols
range.

> In order to make decisions in the case of a trade off such as this, one
> really needs a guiding philosophy.   Mine, which evolved over a long
period,
> is broadly (with regard to the particular features we're discussing) as
> follows.
>
> I draw a score.  I want one of the staves and the music it contains to
be at
> a smaller size.  Typically this would be for a bassoon (say) soloist's
part
> reproduced on the piano accompaniment.  That is a 'cue stave' which can
> contain just about any musical element drawn at the smaller size.   It
makes
> sense therefore to demand that the whole font is used at the smaller
size.
>
> The bassoon switches between bass and tenor clef.   For its own part it
> needs CLEFs (defined for current purposes to be at the start of lines)
and
> CLEF-CHANGES which are 2/3 the size.   These are both also drawn on the
> pianist's cue at reduced size.   It therefore makes sense to implement
the
> CLEFs and the CLEF-CHANGEs as different glyphs in the same font.
>
> The bassoon part may have grace notes in it.   Again these would be
drawn
> reduced on the pianist's cue stave.  So again it makes sense that grace
> notes belong in the font separately from notes, and if they are composed
of
> heads, tails and accidentals, so be it.    You didn't think of cued
grace
> notes?  Glad I got them in first  :-)  :-)
>
> At this point it seems to me to be a coherent philosophy that the font
> should contain both clefs and clef changes, and grace notes (with the
> necessary accoutrements), but that the cued in part is written with a
> smaller implementation of the font.

Er... I'm sorry, but it doesn't seem very coherent to me. The division
between "all full-sized symbols, 2/3rd size clefs, handful of noteheads,
accidentals and flags" and "all cue-sized or cue-sized grace note symbols"
seems arbitrary to me.

Is it not a *more* coherent philosophy that the music font should encode
all symbols once each at their full size, and that a consuming application
should use the font in up to four sizes to draw any required symbol at any
required size?

I'm sorry to be so disagreeable, Dave, really! But your proposed
duplication of such large swathes of the symbols in the standard really
seems like overkill, particularly since you concede that you currently
have to scale the font to draw cue-sized items in your application anyway!

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