Re: [HELP] Change notehead font-size depending on note duration

[Valentin Petzel]

I understand. Maybe we could make sure to evaluate relevant properties in 
music_font_alist_chain should they be a callback? Alternatively we might also 
change the internal callback structure. Kind of if a property is a callback 
((grob) ...) we might wrap it into a function like
(() ((grob) ...) (this-grob))

This would allow us to call the callback property just by the property without 
always having the grob around (and it should not induce problems, as you’d 
normally not call a callback for a grob on a different grob).

Cheers,
Valentin

Am Mittwoch, 2. März 2022, 07:37:52 CET schrieb Jean Abou Samra:
> Le 01/03/2022 à 20:34, Valentin Petzel a écrit :
> > Hello Robert,
> > 
> > the problem here is that the font-size property of the NoteHead is not
> > evaluated. (This happens from time to time, and I’m not sure why this is
> > so.)
> Look at Font_interface::get_default_font. It takes a property alist
> chain from the grob and then applies the font selection mechanism
> to this alist chain. If there are callbacks, they won't be understood,
> and the grob is not available in this part. This is a known dark
> corner in LilyPond's design, caused by the interaction between
> markups and grobs. Font selection works with alist chains because
> that's all you have when working with a markup. Similarly, this
> means that the properties used by a markup that gets interpreted
> by grob-interpret-markup are not automatically evaluated if
> they are callbacks. Better would be changing markups not to use
> alist chain but some kind of overarching data structure that
> could come with a grob or not, and would automatically execute
> callbacks transparently on property accesses. Another possibility
> would be to make the interpretation of standalone markups
> actually handled by a special grob. Yet another one would be
> traversing the markup to resolve all properties it uses (as
> declared by the markup command definitions) beforehand.
> The last one would be less flexible though.
> 
> Best,
> Jean

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