On 21/04/2023 12:03, Kieren MacMillan wrote:
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.
Just to add to bikeshed colours, please DON'T call it "stylesheet". Call
it the same name as the font, or something like that.
If I've got a bunch of custom fonts I use, I just want to dump them in a
directory and forget about them. If they all store their metrics in a
file called "stylesheet.ily" they'll get thoroughly confused.
Indeed, it would be nice to be able to add a top-level command to
lilypond that adds this directory to the list of directories searched
for fonts by default. Dunno how easy that's for you to implement, but it
would make life damn simple for users :-)
Cheers,
Wol
