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