Re: What music font packaging/selection experience do we want?

[Kieren MacMillan]

Hi Jean,

> For those who haven't followed the (long) story, this MR basically lets 
> LilyPond search for music fonts in the same way as it searches for text 
> fonts. It thus makes it possible to make music fonts found with 
> ly:font-config-add-font or ly:font-config-add-directory, in contrast to the 
> current approach where you have to drop them into directories that are 
> normally supposed to be internal to LilyPond (and therefore re-add them with 
> every new LilyPond version). This lays the internal foundation for a better 
> user experience of using alternative music fonts.

As someone who (a) uses alternative music fonts for almost everything and (b) 
upgrades often, this is a welcome MR. Thank you!

> Now, from the user point of view, the question is how we want to organize the 
> UX of using an alternative music font:
>       • Download the font: from where? Are some alternative fonts 
> preinstalled with our official binaries? This would deserve a thread of its 
> own and I won't discuss it here.
>       • Install the font: how?
>       • Use the font in a .ly file: how?
> For (3), the basic way to select a music font is
> \paper {
>   fonts.music = "whatever"
> }
> 
> The main issue is that this only switches the glyphs themselves. However, to 
> look good, there are also other style adjustments to make in order to match 
> the font, like the thickness of stems and staff lines, etc. We want to have a 
> way to select a font and make those adjustments automatically at the same 
> time.

How does this discussion intersect with our/my long-ongoing discussion around 
stylesheets in general? As with SMuFL support, I think it's probably desirable 
to keep broader stylesheet mechanism(s) in mind.

> Now to the second approach, which I prefer.
> In this approach, \paper { fonts.music = "foo" } remains the syntax to select 
> an alternative music font.

I prefer this, too.

> If, next to the .otf font file, a file called stylesheet.ily (or another 
> bikeshed color) is found, it is read and defines the style parameters. 
> Because we want to be able to apply it both globally and locally to one 
> score/bookpart/book, we take it in the form of a \layout block. To do that, 
> we read stylesheet.ily with ly:parse-string-expression. That is, in exactly 
> the same way as the content of #{ ... #} is read. For the stylesheet.ily 
> writer, this means that the file is written as a single \layout block (plus 
> perhaps a \version statement).
> 
> If in the future we support SMuFL, we'll also read the JSON metadata and 
> synthetize a layout from it, then use it in the same way. stylesheet.ily 
> would continue to be supported and could be used to define styles that SMuFL 
> doesn't allow.

How modular and adaptable will that be? In a robust stylesheet system, there 
would be “inheritance”, “cascading”, etc., rather than the “include and 
overwrite” that happens with [ad-hoc] stylesheets now.

> For this reason, I lean towards a -dfont-path option, similar to -I but for 
> font directories, and scanned recursively.
> 
> The downside, of course, is that we'll need to wait until a Frescobaldi 
> update implements a graphical way to add font directories, like include 
> directories, for this become a really seamless experience. (I would be 
> willing to contribute that in Frescobaldi.)

There are lots of things we get in Lilypond that don’t show up in Frescobaldi 
for a while, so this is a trivial “downside”.

Thanks,
Kieren.
______________________________________________

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.