On 4 août 2012, at 09:28, k-ohara5...@oco.net wrote: > On 2012/08/01 06:45:22, MikeSol wrote: > >> Avoid measuring extents when engraving is happening because they could > be >> dependent on other callbacks which could trigger many layout decisions > before >> engraving is finished. > > > This is a case where measuring extents early seems appropriate. > > Phil wants the line-indents, thus line-lengths, thus some very early > layout decisions, to depend on the extents of the instrument names. > > The dependency is reversed in this case from the more usual situations > where Mike's suggestion holds, such as the extent of a hairpin, which > depends on the layout. >
I agree that the calculation will happen early (definitely before line breaking), but if someone writes an exotic callback for the stencil function of instrument name that somehow is linked to other grobs, it should only be called after engraving is done. >> Here, what I would do is use the Pointer_group_interface to add two > grob arrays > > Running through those arrays and re-checking the lengths of the > instrument names every time we look up the line-indent, would let the > line-breaker see if those lengths changed for some reason depending on > the evolving layout. I do not expect the line-breaker to behave > sensibly if the indents change like this. I didn't express myself clearly. I meant that there should be a finalize method in the engraver that loops through the vectors and adds them to a grob array via Pointer_group_interface::add_grob. finalize is only ever called once for a given engraver. > >> Properties, in LilyPond, are the best way to stash >> information. > > Phil, working with properties, or in this case Scheme variables > associated with layout, does seems necessary. See set_variable(). > Old scores where we chose \paper {indent = 2.3\cm } to fit the > instrument names should continue to work. > If you can figure out enough Scheme to have LilyPond initialize indent > so that it evaluates a different Scheme variable (say, default-indent) > and have the engraver updates that variable, then we can have > automatically-adapting intends by default, and let users override by > replacing the link to default-indent with their own choice. > > http://codereview.appspot.com/6457049/ I agree that users should be able to override something, but they should be able to override a property of InstrumentName or System (depending on how things are implemented). I'm always wary of Scheme variables because of global scopes and multiple scores: that has come to bite me in the past. I generally steer clear of this approach and try to make things grob-centric (or if necessary prob-centric). There are some things that fall outside the scope of grob-related issues (like the paper bloc) but I think it's best to try to use grobs, callbacks, and properties as much as possible. I'm definitely not saying that your solution won't work, but I think that going down the grob road is more architecturally sound. Of course, if Phil has time, he can investigate the plausibility of both :-) Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel