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

[David Webber]

From: Daniel Spreadbury

> Is it the job of the music font itself to encode such semantic differences
as the (to my mind, highly debatable) difference between a clef at the
start of a system and a clef change elsewhere in the system?  <

Yes.  Ultimately every symbol in the font is there because it has a semantic
significance.  Otherwise on might just as well blit every pixel.

>> As things stand...

> Perhaps you can explain to a non-technical dummy like me what the real
underlying technical problem is here that makes it so undesirable to use
the same font at a variety of sizes while drawing the score.  <

It's to do with the definition of a font, and the objective of unicode.
For text applications the idea is that you should be able to write out your
document using a collection of characters, at a certain point size, known as
a font, and that you should only have to switch fonts when you want a
different style (or to switch to a different overall print size), eg for a
heading.   It seems reasonable and elegant that you should be able to do the
same with music.

Instead we can write out almost everything in a part, but if there's a clef
change we have to borrow the symbol from another font - eg a 16 point music
font instead of 24.    That just feels like such a kludge.

> It sounds to
me -- and pardon me if I have misunderstood what you've said -- as if you
are already using the font at at least *four* sizes anyway in Mozart: <

Three:  one normal, one for cue notes, and one for chord symbols like G7
(which various requests wanted me to allow at different sizes relative to
the music).

> So what is two more required sizes between friends?

I regard it as one of the least pleasant features of the program and would
like to do with fewer (biut haven't worked out how to yet).  But in any
event each strand of notes etc tends to come from a single font.

> I know from the experience I had working with the team on Sibelius that
changing pens and fonts can be a somewhat expensive operation in
performance terms, particularly if you do it thousands of times. <

That is one of my motivations.

>For
years, Sibelius's drawing operated in a strict "top to bottom, left to
right" order, so it was swapping pens and fonts all the time (first draw
staff lines, then get a font for the clef, then get a font for a note, now
draw a stem, now get a font for a dynamic, etc., etc.).

I can imagine that this was awful.   Mozart never ever had to do that.

> Once we
implemented Magnetic Layout in Sibelius 6, which required a proxy for
drawing before working out the collision avoidance, we could pipeline the
drawing to a great extent so that all items that used the same pen or font
at the same z-order position could be drawn successively without swapping
pens and fonts, which gave a significant performance boost.  And perhaps
Mozart already has a more sane and performance-optimised drawing mechanism
in place anyway. <

It's much simpler than that sounds.  Mozart only changes fonts in order to
draw a line of chord symbols or a line of cue music, which will usually, I
guess, be two or three times at most on a screen.  [Cues tend to be
organised so that they are drawn in a sub-operation searate from the normal
music, so there isn't any rapid alternating.]     [And Mozart initialises
all the font sizes once before the drawing operation - there are only 3 so
it isn't as big an overhead as having an arbitrary number and initialising
them on the fly.]  Mozart is also very careful not to redraw the more of the
screen than it absolutely has to, though I'm about to experiment and see how
much performance is lost if I do whole screen redraws more often, as it will
make life much simpler.

> Yes, but to what extent is *any* digital typeface a font in the
traditional printing sense?

I think there's a very strong relationship with the original moveable type
concept.

> I know Emil has already pointed out that in
typography it is not uncommon for text font families to include "display"
variants designed for printing at large sizes and "caption" variants for
printing at small sizes, for many (possibly most) families it is instead
expected that the same font must be drawn at several sizes to achieve
things like headings, body text, captions, footnotes, and so on, within
the same document.<

Absolutely - but a clef change within a line of music is not in the
slightest bit analogous to putting a title in a different font.   It's like
having one letter in the middle of a paragraph n a different font.

>My objection is really about the amount of duplication that your proposal
requires.

As I pointed out in the previous message having characters which are the
same shape but different sizes 's' and 'S' is not always 'duplication' -
it's only duplication if you think they're the same character.  And there's
so much duplication there already (eg the whole Musical Symbols Area) that
I'm surprised that you object.

> You have conceded several times in this discussion that
duplicating all these symbols at cue size is probably a step too far.

Yes - I' d love to find a way round that, but I suspect it is a step too
far.

> How about taking one step further back still? ;^)

But it's a different kind of step.  Cue notes come in (shorter or longer)
sequences of symbols to provide the cue.  Normal notes also come in (long)
sequences of symbols.

Each such sequence can, without too much inconvenience, be drawn with a
singe font size.  Except that there are just one or two random symbols (a
clef change or a pair of grace notes) which completely interrupt the flow by
demanding a different font size.

Dave

David Webber
Mozart Music Software
http://www.mozart.co.uk/



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