On Tue, Aug 31, 2010 at 12:34 PM, Mike Solomon
<address@hidden> wrote:
Hey all,
I recently tried to programmatically add a pure-print function to the
list of pure-print functions using the setter method I proposed, which sent
lilypond into a 13+h spiral of compilation in functions having to do with
skylines and page breaks that I don't really understand (this is what gdp
tells me). In order to create a print function that works as a pure-print
function, is there a series of steps one has to go through:
(a) to design the function (is there anything that a pure-print callback
neeeeds to do or not do, both in terms of its return value and internal
operation)?
It must not have any side-effects and it must not assume that line-breaking has already happened. So, for example, you should be careful about Grob::relative_position because the x-position might depend on horizontal spacing (which depends on line breaking) and the y-position might depend on the distance of staves from one another (which depends on line breaking). Also, many extent callbacks have side-effects. Many functions that are dangerous in a pure function have pure versions (for example, Grob::pure_y_coordinate), so you can use them instead.
(b) to register the function in various places (what parts of lilypond aside
from the list pure-print-callbacks in scm/define-grobs.scm need to know
about these functions)?
That's all.
I should mention that the only reason to add a pure print callback is so that Grob::pure_height gives a good height-estimate for your grob. There might be better ways to achieve the same thing. For example, if your height callback is already pure, you can add it to the pure-functions list. If your height callback is not pure, but it is easy to write a pure approximation, you can do so and add the conversion to the pure-conversions-alist.
Cheers,
Joe