Re: Uses single algorithm for side-position spacing. (issue 6827072)
On 2012/12/22 16:11:10, mike7 wrote: On 22 déc. 2012, at 07:43, mailto:k-ohara5...@oco.net wrote: https://codereview.appspot.com/6827072/diff/34001/lily/axis-group-interface.cc#newcode62 lily/axis-group-interface.cc:62: return SCM_BOOL_T; Now the whole note-column is marked cross-staff if its stem spans staves. Check if Note_column::cross_staff_extent() still makes sense It does, because this function is a replacement for Grob::extent for NoteColumns. Axis_group_interface::height, even in unpure, won't take cross-staff stems into account. The function Axis_group_interface::height() does not seem to skip cross-staff grobs; it calls functions that eventually try to set stem directions, including those for cross-staff stems. https://codereview.appspot.com/6827072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds dimension stencil command to correct with-dimension (issue 12957047)
There is also \pad-markup and \pad-to-box Also, the delayed stencils in \with-link and \page-ref could use this method to reserve the size of the place-holder text Also, harp-pedals.scm could use this method instead of the invisible box (which is not quite invisible in PNG output and maybe others). https://codereview.appspot.com/12957047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds dimension stencil command to correct with-dimension (issue 12957047)
This looks very promising! Thanks for the work on this. https://codereview.appspot.com/12957047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds dimension stencil command to correct with-dimension (issue 12957047)
I had time to implement everything but the delayed markup stuff. I'll try to get to that soon... https://codereview.appspot.com/12957047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds dimension stencil command to correct with-dimension (issue 12957047)
It was easier to implement the delayed stuff than I expected, so I got it done. https://codereview.appspot.com/12957047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: untangling the remaining regressions
Positioning properties like 'Y-offset' are often linked to callback functions. When it is time to place a grob, LilyPond calls that function and stores the result in the property 'Y-offset', overwriting the link to the callback function. Sometimes, most notably during line/page-breaking, we want *hypothetical* positions: where a grob would be placed *if* line-breaking put paper-columns 'start' through 'end' on one line. We do not want to evaluate every positioning callback, and even if we did there is no mechanism to restore all the links to the original callback functions, so we use estimates of positions through 'pure' functions. 'Pure' functions can look up a 'Y-offset' if it is data, but are not usually permitted to use a callback function. There are utility functions named maybe_pure_*() that look up properties that are data, but refrain from using most callbacks. The exceptions, callbacks that may be evaluated, were previously enumerated in lists; now they are simply those functions wrapped in an unpure-pure-container. 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. 'pure' could now mean simply: this function promises to change no grob data. It may cache data, and perform output, and other procedural things, so long we retain our ability to evaluate more hypothetical layouts. The various functions labeled pure do not all keep this promise. (My struggle today was using pure_vertical_stencil_from_extents on a note-column, and finding it set the cross-staff beam position, through various paths.) The code before Mike's two big commits does not seem perfect in this regard either. '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. Positions of cross-staff grobs could be estimated (and sometime are through 'pure' function calls) but they are most often ignored. All non-cross-staff grobs must find their positions while the positions of cross-staff grobs remain hypothetical. That is, any positions callbacks for a non-cross-staff grob may use only 'pure' functions to access properties of cross-staff grobs. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: untangling the remaining regressions
On 22 août 2013, at 11:19, Keith OHara k-ohara5...@oco.net wrote: Positioning properties like 'Y-offset' are often linked to callback functions. When it is time to place a grob, LilyPond calls that function and stores the result in the property 'Y-offset', overwriting the link to the callback function. Yup. Sometimes, most notably during line/page-breaking, we want *hypothetical* positions: where a grob would be placed *if* line-breaking put paper-columns 'start' through 'end' on one line. We do not want to evaluate every positioning callback, and even if we did there is no mechanism to restore all the links to the original callback functions, so we use estimates of positions through 'pure' functions. 'Pure' functions can look up a 'Y-offset' if it is data, but are not usually permitted to use a callback function. There are utility functions named maybe_pure_*() that look up properties that are data, but refrain from using most callbacks. The exceptions, callbacks that may be evaluated, were previously enumerated in lists; now they are simply those functions wrapped in an unpure-pure-container. 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. 'pure' could now mean simply: this function promises to change no grob data. It may cache data, and perform output, and other procedural things, so long we retain our ability to evaluate more hypothetical layouts. Agreed in the big picture and I think it'd be good to come up with rules to test for this during debugging. In LilyPond terms, we do not want set_property, set_object, suicide or translate_axis ever called as the result of the evaluation of a pure function. set_property, set_object, suicide and translate_axis are evil expedients, as they often break the LilyPond callback model. Whenever something goes wrong with the new skyline code, they are called somewhere. The various functions labeled pure do not all keep this promise. (My struggle today was using pure_vertical_stencil_from_extents on a note-column, and finding it set the cross-staff beam position, through various paths.) The code before Mike's two big commits does not seem perfect in this regard either. Yup, this has been a problem for a while but has been hidden. 'cross-staff' marks grobs whose positioning (relative to their parent) depends on the spacing of staves on the page. Yup. 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. Nope. 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.). All non-cross-staff grobs must find their positions while the positions of cross-staff grobs remain hypothetical. Yup. That is, any positions callbacks for a non-cross-staff grob may use only 'pure' functions to access properties of cross-staff grobs. Yup. Excellent e-mail! Worth archiving and reading for future developers. ~Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: untangling the remaining regressions
Keith OHara k-ohara5...@oco.net writes: The various functions labeled pure do not all keep this promise. (My struggle today was using pure_vertical_stencil_from_extents on a note-column, and finding it set the cross-staff beam position, through various paths.) The code before Mike's two big commits does not seem perfect in this regard either. '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. With regard to getting our backend into working order, we are currently doing hardly better than treading water, putting up a fight for making more forward than backward progress. On our wishlist are user-definable grobs. If their placement mechanisms required the sort of work that we currently have with regard of getting the regressions under control, they are clearly far out of the range of feasibility. Not because they are impossible to provide, but because they would be impossible to use correctly. Your whole letter most definitely should be placed in the CG right now: it is an excellent overview of the current state. And we should work hard on being able to throw the whole of it out again in few years. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes how mensural flags are drawn (issue 13122044)
Please review. https://codereview.appspot.com/13122044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes how mensural flags are drawn (issue 13122044)
LGTM, thanks. In case you have time, you might replace
{ foo } z1 { bar }
with
{foo}z1{bar}
for consistency with other files, but this is not really important.
https://codereview.appspot.com/13122044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
