bug-lilypond
[Top][All Lists]
Advanced

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

Re: Output break positions (question or feature request)


From: David Kastrup
Subject: Re: Output break positions (question or feature request)
Date: Mon, 12 Jan 2015 10:28:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> Hi,
>
> as asked on the -user list I am looking for a way to collect the
> positions of all breaks in a LilyPond score.
> http://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00185.html
> suggests that at the time engravers are doing their work the line and
> page breaking hasn't been performed so engravers can't help with
> that. But I'm quite sure LilyPond *has* a way to produce this
> information somehow.
>
> The goal is to find a way to recompile just a certain page or system
> using the skipTypesetting property, which works well for entering or
> editing music as long as the changes don't require changed breakings
> (which would then require a complete recompilation, resulting in a new
> list of breaks.
>
> So I have
> a) the question if there already *is* a way to retrieve the moments
> (barnumber plus measure-position) of all explicit and implicit breaks
> in a score and write them to a log file?
> b) if it's confirmed that currently there is no way to do so please
> add this as a feature request to the tracker.

We had discussed this or something related at some point of time, maybe
David Nalesnik remembers more.

It probably involves the after-line-breaking hook of some grob, getting
the respective ly:spanner-bound of the broken pieces and take a look at
their

     (when ,ly:moment? "Global time step associated with this column
happen?")

property (this documentation string is pretty messed up and probably
warrants fixing).  I think it is something like a pair of global time as
well as measure position.

Sorry that this is not more than a bunch of handwaving keywords right
now, but I think that there is a reasonable chance that it's at least
the right kind of keyword...

-- 
David Kastrup




reply via email to

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