On 6/16/2022 3:01 PM, Jean Abou Samra wrote:
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.
Thanks as always for your detailed explanations, Jean.
My interest stems from trying to understand memory usage at various
stages and whether there's anything I can do to conserve memory, like
perhaps inserting my own \breaks, but that's a whole 'nother thread.
Jeff
