On Sat, Nov 19, 2022 at 3:23 PM Jean Abou Samra <j...@abou-samra.fr> wrote:
> Le 17/11/2022 à 23:02, Jean Abou Samra a écrit : > > Le 17/11/2022 à 23:01, Werner LEMBERG a écrit : > >>>>> But how do you take into account the constraints from lyrics here? > >>>>> That is the whole problem. > >>>> They should be completely ignored. > >>> In that case, it should be completely doable even in Scheme now. > >>> (I started writing some code yesterday in response to Abraham that > >>> does essentially that, maybe I'll have it finished today). > >> Aah, nice! > > > > No so fast, wait until it actually works before calling > > it nice, otherwise if it doesn't work I'll feel bad :-) > > > > > Here you go. > > This is a vast refinement of the initial \autoMove function that takes all > lyric words into account simultaneously, finding an optimal solution that > minimizes the distance from each lyric word to its note while respecting > the minimal distances between lyric words as configured by > LyricSpace.minimum-distance / LyricHyphen.minimum-distance. > > I used the first algorithm with acceptable complexity that I could > think of, so there may be a simpler solution for this. Nevertheless, > it runs in linear time, so I'm happy enough. (If it were quadratic > or worse, the running time could potentially be problematic if > ly:one-line-auto-height breaking is used, in which case there can > be lots of lyrics on the same line.) > > Caveats: > > - As said in a previous message, this is the other extreme compared > to what LilyPond does by default: lyrics are not taken into account > *at all* into note spacing. In particular, LilyPond may produce > a page breaking configuration in which there are too many notes on > the same system to fit the lyrics comfortably. I expect that using > \break in those cases will often be enough to get an acceptable result, > but I have zero experience with typesetting music with lyrics. > (And little actual practical experience with typesetting music at > all, to be honest.) > > - I have barely tested it. > > Additional featurelets: > > - You can still set LyricText.self-alignment-X. It defines the position > of the LyricText that the algorithm will consider optimal. > > - You can set LyricText.details.strength to tell the algorithm to > place one specific syllable closer to its note at the expense > of the others. See the example. > > Before someone asks: this is not good to integrate into LilyPond as-is, > because it breaks assumptions that grob implementors and LilyPond in > general make (namely, the assumption that the X-offset of an item is > known before line breaking). One would have to either go for a full > solution as brainstormed in one of my earlier messages, or at least > find a way for an Item to declare that its positioning depends on other > things (akin to the current cross-staff property, but preferably less > invasive). > > Hope that helps, > Jean > > This looks absolutely amazing! I'm running into some compiler issues when I try to run it on my machine, but I'll see if I can work out why and let you know if I'm unable. Either way, bravo! The output looks like it will fix many situations automagically. This seems to be a fantastic step in the right direction. Generally, I end up controlling the system breaking in the end, anyway, so I'm not too concerned about the possibility of too long a line. Many thanks, Abraham
