[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Retrieving information about breaks (was: Partial compilation (again))

From: Urs Liska
Subject: Retrieving information about breaks (was: Partial compilation (again))
Date: Fri, 23 Jan 2015 16:33:31 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Picking up that old thread seems better than starting a new one ...

By now I've reached a different state and would like to come back to this issue with a very concrete question: Is it possible to determine at which positions (in terms of barnumber and measure-position) the final line breaks, page breaks and page turns have been placed in LilyPond? I'm sure this information has to be present at one point, but someone (I think it may have been David Nalesnik) expressed the opinion that engravers could only access explicit \break-s.

I would like to write out a log file containing all break points of a given LilyPond run.

If that's not currently accessible I'd like to add that as a feature request.


Am 21.11.2014 um 14:44 schrieb Urs Liska:

Am 21.11.2014 13:33, schrieb David Kastrup:
Urs Liska <address@hidden> writes:

Am 21. November 2014 12:36:59 MEZ, schrieb David Kastrup <address@hidden>:

So I don't see this going anywhere fast.  To get a hook into cloning
internal engraver states, you'd probably want to create a more
object-oriented frame work for them.
Ok, I see. Thank you for the explanation.

I'll try if I can get *somewhere* with an "external" approach as
outlined on -user.
TeX, in contrast to LilyPond, works in a pipeline-like manner, producing
output all the time.  In that case, a semi-external approach might work
when you have a good idea what kind of input is subject to editing: you
just fork off a copy of the executable when it gets to the place before
the editing region.  And then you run that forked copy on the changed
input from that point on.

However, LilyPond first consumes all input and then starts processing,
so the input file pointer into an unchanged part of the input is just
not a useful indicator of LilyPond's progress and this kind of low-level
approach does not look workable.

OK. I will try around anyway.
If I knew where a given system starts in terms of barnumbers I can try:

- setting suitable skipTypesettings commands one measure before and one measure after the range - check for open spanners and optionally inject corresponding starts/ends in the respective "preroll" measure
- add manual breaks before and after the line
- compile this threeline document to three temporary files (with lilypond-book-preamble)
- replace the respective previous system's pdf with the new one.

setting system-count to 3 will result in the right document in any case, and in warnings when the system gets too full (so the recompilation doesn't work anymore).

Of course this isn't intended for the part of bringing a score to publication quality but rather for the stage when you're only dealing with the content. And I don't know how complicated things will become. But I think it is worth a try.


lilypond-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]