Re: is "pure positioning" done per score or per bookpart?

[Jean Abou Samra]

Le 16/06/2022 à 01:35, Jeff Olson a écrit :
> Jean,
>
> I'm studying your "Overview of LilyPond’s inner workings" 
> (https://extending-lilypond.readthedocs.io/en/latest/intro.html#overview-of-lilypond-s-inner-workings-and-how-you-might-hook-in-them) 
> and trying to correlate the processing steps you describe with the 
> INFO level output that I can see in the log.
>
> Knowing my piece, I can discern in the log what's done e.g. for every 
> score from things that are done for each bookpart:
>
>    per compile:   "Parsing..."
>    per score:     "Interpreting music...[8][16][24][32][40][48]"
>    per score:     "Preprocessing graphical objects..."
>    per bookpart:  "Finding the ideal number of pages..."
>    per bookpart:  "Fitting music on 39 or 40 pages..."
>    per bookpart:  "Drawing systems..."
>    per compile:   "Converting to <myfile>.pdf"
>
> But what is not self-evident is whether the stage you label as "Pure 
> Positioning" is done per score in "Preprocessing graphical objects..." 
> or per bookpart in "Finding the ideal number of pages...".
>
> Since pure positioning is done a priori, before breaks are decided, it 
> could be per score.  But the word "ideal" in the log might 
> alternatively match with "pure".
>
> This off-by-one ambiguity cascades through the subsequent stages and 
> their correlation with log messages, but surprisingly both 
> possibilities arguably line up with the log.
>
> I guess I could equivalently ask whether the stage "Writing Output" is 
> done for each bookpart or once for the whole compilation.
>
> If you're still taking suggestions re 
> extending-lilypond.readthedocs.io, it might help others if each of the 
> processing stages listed in the Overview explicitly said how they 
> appear in the log, since those phrases are often familiar even to 
> Frescobaldi users.



Good question! It happens mostly in the "Preprocessing graphical
objects..." step. The truth, however, is that this "phase" is a
simplified view, which I gave to make the whole thing a little
more approachable. Unlike, for example, conversion from PS to PDF,
there isn't really a point of the compilation where LilyPond
thinks "OK, at this stage the next thing I need to do is pure
positioning". All properties in the backend use a lazy model,
which is explained in more detail in the "Backend programming"
part of extending-lilypond.readthedocs.io. Basically, grobs
contain specifications of how to compute their properties, whether
pure or not, and when something somewhere needs a property,
the computation is triggered. The flow is:

- Parsing,

- Interpreting,

- "Preprocessing graphical objects": at this point, the game
  is to find out horizontal spacing. This requires knowing a bit
  about the height of some grobs, like stems, so you know what
  distance there must be between two notes to avoid any collision.
  This is where LilyPond uses a lot of pure estimations, since
  exact info is in many cases not available at that point (a stem
  might be part of a beam, which will not be able to determine
  its slope before it knows the distance between its endpoints,
  which needs horizontal spacing, and you're precisely trying
  to determine horizontal spacing). Similarly, it figures out
  the approximate (pure) height of various parts of the score
  so that the page breaking algorithm can know how many systems
  it is good to put on a page.

  As you can see, this is the phase where pure info is really
  useful. Nothing prevents from using it elsewhere, though.
  This is actually done a little bit in "Drawing systems" too.

- Then you have "Finding the ideal number of pages" and "Fitting
  music on x pages", corresponding to page breaking and line breaking.

- "Drawing systems" is the real ("unpure") positioning and final
  computation of all stencils and offsets.

- "Converting to file.pdf" is the conversion from PS to PDF
  by GhostScript.

I'll try to clarify that, and it's a good idea to include the
log messages. Thanks for your feedback.

Cheers,
Jean

PS:

> I guess I could equivalently ask whether the stage "Writing Output" is 
> done for each bookpart or once for the whole compilation.


"Writing output" is a very simple stage: take the PS file, convert
it to PDF format. It's just a format conversion, so it happens
per book. Several \book blocks lead to several output PDF files
and consequently trigger this several times. It's just happening
once per output .pdf.