Jean Abou Samra <j...@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
