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.
