David Kastrup <dak <at> gnu.org> writes: > "Keith OHara" <k-ohara5a5a <at> oco.net> writes: > > > 'cross-staff' marks grobs whose positioning (relative to their parent) > > depends on the spacing of staves on the page. These grobs have to be > > positioned last, after all grobs moving with their parent Staff are > > positioned relative to him, and staves are spaced. There is not an > > overarching mechanism to enforce this timing. > > Given the complexity of getting these kind of things right manually, we > most definitely _want_ an "overarching mechanism" in place here.
It is not yet completely clear to me what the mechanism needs to do. For most cases, we know that vertical-position properties like Y-extent and *-skylines on a cross-staff grob should not be finalized before staff-spacing is done. Maybe grob_property() can check, before calling a callback function, whether the grob in question is marked cross-staff. and if so check whether staff-spacing is done. If the grob is cross-staff but staff-spacing is not done, only a 'pure' version of the callback function can be used, and if none is available we can only return 'nil'. It is not clear whether grouping objects that contain some cross-staff grobs should be marked 'cross-staff'. NoteColumn is an example. For now, with anything marked cross-staff getting no spacing reservation at all, it is better to leave the groups unmarked and have their 'extents' and 'skylines' enclose the non-cross-staff parts of the group. If and when each type of grouping object gets a callback that returns the extents of its non-cross-staff portion (probably through a pure callback) and also the extent of the entire group (through a non-pure callback) then it would seem more useful to mark the group as cross-staff if any member is cross-staff. Mike Solomon <mike <at> mikesolomon.org> writes: > > When such a container is accessed through a 'pure' function-call, > > its return value is *not* stored in the grob property, so the link > > to the unpure-pure-container remains in place for the next use. > > Yup, with the notable sort-of-exception of Items' pure height, > which is cached and reused to speed up computation time. That's not really an exception, because the cached values are stored in a C data-structure, not the grob property. Spanners, as opposed to Items, cache *every* return value from a 'pure' function-call this way, so that if the same value is requested for a hypothetical line with the same 'start' and 'end' columns, the cached value is returned again. > > Positions of cross-staff grobs could be estimated (and sometime are > > through 'pure' function calls) but they are most often ignored. > > This is the basis of all my stub work (SlurStub, etc.). Well, the SlurStub is invisible but has an extent to make up for the fact that the extent of a cross-staff Slur is ignored. It seems it would be simpler if Slur itself had a pure version of its Y-extent callback, and if that callback were used to reserve space for an estimated slur position. _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
