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

[David Webber]

From: Daniel Spreadbury

> 1. As Daniel said - ther's a performance hit.

> Though not a significant one, of course, and since working with fonts is a
pretty standard OS operation, there's generally good automatic caching and
so on.

One would try to minimise it - but having a separate font instance at 2/3
size *just* for clef changes is really horrible.   [Even if you have to
switch to yet another size for grace notes you'd probably end up using up to
a dozen characters from it - in some pieces.]

As I said, its like writing "Susan" with

"Su"
Damn! the font has no lower case s
so switch to another one 2/3 the size
"S"
switch the font back
"an"

>> 2. I'm sorry you don't regard Mozart (v1 released 1994) as 'current
>> software'.   I'm beginning to realise we're designing fonts for Sibelius
and
>> Finale.

> That's a bit of a low blow...

Not really: to be told after I have been writing music software for 25 years
and selling it for 19, that I should do it like "current software" does it,
is about as insulting as anyone here could try to be.   But I had only just
woken up this morning to find that message, and it hurt - normally it is
more like water off a duck's back: my software has been insulted in the
past, almost always by people who have never tried it.

But effectively, that's what Mark was saying:   that SMuFL should be a font
specification, but only for platforms which support OpenType fonts, and for
programs which use the same drawing procedures as Sibelius and Finale.

>It's certainly not a stated goal to design
fonts only for Sibelius and Finale, though I hope that both Sibelius and
Finale (and Noteflight, and Lilypond, and Mozart, and MuseScore, and
Logic, and Cubase, and on and on) will be able to make use of
SMuFL-compliant fonts if they wish.  <

So do I - that's why I am here.

I could make Mozart use these fonts the way Sibelius does, but it would be a
lot of work for a huge step backwards.  (And whilst I have great admiration
for Sibelius, I don't think it fair to assume that it cannot be bettered in
any aspect.)

But I am trying to argue from the point of view of Unicode, and the way it
is used (in the most general sense).

Adding characters in a different style is fine, if you want characters in a
different style.   So in text you may switch styles to put a passage in
italics, for example.   But to have one character in the font where you have
to switch to italics (or some other style) every time you want to put it in
a passage of normal text would be silly.   The clef changes represent
exactly that.  (We can argue about the merits of grace notes later, and I've
already conceded that I can't think of a better way than you're proposing
for cues.)

So if we think about styles: italics is a different style, and you switch to
italics to write entire passages.   The 'long s' is also a different style
of s, but that's a one off, and it can be used both in normal text and in
italics.  It makes no sense to include it in the font as a style variant -
so it has its own code point.  So you can use it in simple text strings with
no problems:  here's 'fast classics' written with the long s:

<http://www.mozart.co.uk/various-ilustrations/codepoint-example.jpg>

(and I included the f to prove it's not an f!)  The whole text is output
with a single call to the windows API function ::TextOutW().  No font
changes.

> And if they don't wish, hey, they can
keep doing what they're doing, or invent their own new standard if they
like!

Mozart already has its own standard, and one 3rd party font supplier has
provided fonts to it.   I was sort of hoping for a wider standard, and am
anxious to make it as usable as possible (for more than just Mozart).

Perhaps it would be a useful exercise to put OpenType out of mind for a
moment and think about supplying good old fashioned non-scalable font in a
couple of different sizes.   Can one draw music like that?   [THis throws
the focus onto Unicode code points.]

Well, as far as I can see, currently the answer is almost 'yes', as long as
the font is supplied in 3 sizes: one for normal music, one for cue notes,
and one for grace notes.  The sole exception (as far as I can see at the
moment) is that you can't print clef changes.   That would require a fourth
size of font, just for the 3 clef-change symbols.

> I think the clef argument is slightly stronger than the argument for grace
notes,

The above tends to support that :-)

> cue notes

and I can't (so far) think of a better way of handling cue notes than with a
smaller instance of the whole font.   But if grace notes were included in
the main font in their own right, you'd get cued grace notes automatically
by this mechanism.

> I suggest we park this particular discussion for now. We haven't reached
consensus, and several of us are expending a lot of time and energy on
this issue. I have got a note of it as an open question, and we can return
to it in due course.<

Fair enough - I have work to do :-(     But I do think it is fundamental to
the general design of a *font*, as opposed to a collection of symbols.

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