Re: SMuFL

[David Rogers]

Klaus Föhl <address@hidden> writes:

> Hello,
>
> When changing font in text processing, you switch to a different font,
> and most time that's it. Relative placement is taken care of 
> by the provided font metrics.
>
> In music notation there is a font, but at least within Lilipond objects
> like staves are draws not using glyphs from fonts but more primitive
> graphics objects. So I feel one should also change the layout of quite
> a few graphical objects when switching fonts.
>
> I wonder whether one would call that "layout" or "style".
>
> In the current SMuFL paper (Version 0.4) there are some options:
>
> use complete notes as provided, or assemble from notehead, stem and flag
> ? is there some guidance how to match stem height to flag for
> best visual appearance ?
>
> use complete brackets, or assemble (and combine with a non-font line)
> ? What line thickness to go with U+E003 / U+E004 ?
> ? Should there be a vertical line in the font with such thickness ?
>
> use the staves (with the line thickness as provided) or draw lines
> While "Scoring programs should draw their own staff lines using primitives" 
> ? does the font tell you what the line thickness should be ?
>
> So how to package this ancillary information to go with a "font"?

This question has been a problem essentially forever, even from before
computers - clefs and brackets are often engraved separately from notes,
etc.

Some computer music typesetting software has essentially declared
"Everything we print is a character in a font, even staff lines". Other
software has gone in other directions.

In the context of good typesetting, the answer is "It doesn't really
matter, just do the best most efficient job possible."

I think, in the context of Lilypond, the best answer is "Package the
information in such a way that the creator of a new Lilypond font will
be able to understand what he needs to do without having to navigate
Lilypond internals or know how the typesetting works".

Or, to put it another way, the document "How to Create a Lilypond Music
Font" should ideally be short, and able to be understood and
successfully applied by someone who knows fonts but doesn't know
Lilypond.

Right now, such a "font person" tries to make a Lilypond font, gets
quite some way into the work, and finds these few lines buried in the
documentation:

"Step 893: Re-write Lilypond to accommodate what you've created in the
preceding 892 steps. This step is left as an exercise for the
reader."

"Step 894: If you are religious, you should take some time to pray
now. Even if you're not religious, praying is still recommended, just in
case."

"Step 895: I thought that might happen. Too bad. Oh well, go back to
Step 1 and let's try to see what went wrong."

 :)

I have no illusion that making a font for Lilypond should be easy. I
_do_ have the illusion that it ought to be a clearly-defined task.* If,
in Lilypond's case, "Font" means more than it does in other situations
(for example, if for Lilypond a font designer must provide a lot of
additional measurements or extra glyphs), well, so be it. As long as
he's told what the requirements are, and how to ensure that his new font
will actually work.


* - It's easy to see that the history of Lilypond development might have
  meant that at one time there was a lot of pressure to "get it working"
  and very little pressure or desire to "get it ready for different
  music fonts".

-- 
David R