Re: untangling the remaining regressions

[Keith OHara]

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.