[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: Wols Lists
Subject: Re: What music font packaging/selection experience do we want?
Date: Fri, 21 Apr 2023 13:47:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

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 
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 :-)


reply via email to

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