[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kieren MacMillan
Subject: Re: What music font packaging/selection experience do we want?
Date: Fri, 21 Apr 2023 07:03:14 -0400

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 {
> = "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 { = "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”.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]