lilypond-devel
[Top][All Lists]
Advanced

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

Re: \fine, pre-process-in-final-translation-timestep & co.


From: Jean Abou Samra
Subject: Re: \fine, pre-process-in-final-translation-timestep & co.
Date: Sat, 9 Jul 2022 23:45:43 +0200


> Le 9 juil. 2022 à 22:08, Dan Eble <dan@lyric.works> a écrit :
> 
> Do you have any concern about other engravers might have acknowledged the 
> grobs that are about to be killed, which might have performed interesting 
> actions assuming that the grobs would continue to exist on one system or 
> another?  Does the battle-tested algorithm sort out all the consequences of 
> creating those grobs?


I won’t know for sure until it has been tried out and all the code paths can be 
seen. I don’t anticipate major problems right now, although it has been a long 
day and I might be missing something.

I see that I expressed myself poorly with ‘battle-tested’. It’s more like: the 
code is written to work that way and has received a lot of thought, so if 
break-visibility etc considerations are viewed as a sane way of doing the cut, 
that body of code can be profitably reused. For what it’s worth, doing it that 
way is _not_ a panacea in general either without some further thought: taken 
as-is, it will make clef/time/key changes right after fine print a dangling 
clef/time signature /key signature at the end. I’m not sure how to solve that 
in general. I think the idea of cutting spanners should work out well enough. 
For items, some more thinking is needed.

Also, one thing you would need to be careful about is how references are 
rearranged (the equivalent of break substitution). While different systems live 
mostly independent lives after line breaking, some routines do need to look at 
other systems. I _guess_ the sanest way would be to eliminate those references 
completely instead of leaving them as references to dead grobs.

In short: this is not the kind of idea I can crank out code for in two minutes.





reply via email to

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