lilypond-devel
[Top][All Lists]
Advanced

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

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


From: Jean Abou Samra
Subject: Re: What music font packaging/selection experience do we want?
Date: Fri, 21 Apr 2023 13:18:18 +0200
User-agent: Evolution 3.46.4 (3.46.4-1.fc37)

Le vendredi 21 avril 2023 à 07:03 -0400, Kieren MacMillan a écrit :

> 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.

"Inheritance" is a form of "overwrite", isn't it? ;-)

You are right that this all begs questions about stylesheets. However, this 
proposed system is little different from what LilyPond currently does, and as 
such I don't think it would hamper the design of a refined stylesheet system.

It would be essentially equivalent to adding a `\layout` block with settings 
for the font wherever you put a `\paper { fonts.music = "..." }`. (Except that 
`\layout` isn't allowed in `\book`, but I hope to make this mechanism work 
nevertheless, until we can make `\layout` work there.)

You could achieve modularity for font stylesheets using `\include` inside the 
`stylesheet.ily` file, but I don't expect use cases. If there is something in a 
font stylesheet that also needs to be shared with something else, it sounds 
like something that's not intrinsically related to the font and shouldn't be 
part of a font stylesheet in the first place. For example: if you create a font 
that reproduces editions from publisher Foo from the XVIIth century, the 
thickness of stems sounds like something that should be part of the font 
stylesheet, but I think spacing overrides should be kept in a more general 
stylesheet that both sets that font and makes other settings to look exactly 
like what you're reproducing.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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