Re: Flexible lyric alignment

[David Kastrup]

Jean Abou Samra <jean@abou-samra.fr> writes:

> Le 16/11/2022 à 10:05, Werner LEMBERG a écrit :
>> I draw my idea from LaTeX, for example handling multi-page tables (see
>> the 'longtable' package).
>
>
> I looked at the documentation
> (https://distrib-coffee.ipsl.jussieu.fr/pub/mirrors/ctan/macros/latex/required/tools/longtable.pdf).
> The footnote on the first page says
>
>   The new algorithm for aligning ‘chunks’ of a table used in
>   version 4 of this package was devised coded and documented
>   by David Kastrup.
>
> LOL.
>
> Obviously, David will be able to comment better than me.
> But skimming the documentation of the package, it looked
> more like the package had to use this technique to work
> around the limitations of the extremely limited TeX
> programming environment than to implement a smart
> algorithm. Am I wrong here?

Pretty much so.  The principal constraint "longtable" is working around
is that TeX is designed to keep not much more than one page of material
in memory, so aligning multi-page tables needs a multipass algorithm.
The principal problem the "new" algorithm addresses differently compared
to the "old" one is that of cells spanning multiple horizontal table
slots.  This could make the "old" multipass algorithm converge to a
table that was too wide for its material and might require manual
intervention.  The "new" algorithm always converges on its own though it
may take a number of passes to do so.

The new algorithm is rather tricky in how it ensures convergence.

That programming in TeX is a horrible mess since TeX actually contains
two programming systems, one blind (the "stomach" can change variables
but not branch depending on their values) and one lame (the "mouth" can
branch based on conditions but cannot affect variables) that are tied
together with comparatively stretchy rope (they may execute for longer
code pieces without involving the other).

But this horrible programming mess is a given and not really related to
the algorithm I implemented in particular.  The algorithm is
independently tricky.  That the implementation language(s) suck has
nothing to do with it.

No idea how this would even apply to LilyPond since LilyPond _does_ keep
everything in memory and thus does not require a similar multipass
approach.

-- 
David Kastrup