Re: How the vertical layout engine correctly manages spanners' heights

[Mike Solomon]

Thank you very much Joe.

An improved version is at:

http://www.apollinemike.com/lilypond/vector5.pdf

There are still some kinks: the second staff looks like it’s moved in the wrong direction (up instead of down) in the vertical spacing, and it seems like the second spanner on each line is not offset correctly.  Any ideas from any of all ya’ll would be greatly appreciated.  However, Joe’s suggestion to check out Y-offset callbacks has already helped a great deal, and stuff like the pdf online will certainly be passable for the demos I need to do this weekend.

Cheers,
Mike


On 7/22/10 8:35 PM, "Joe Neeman" <address@hidden> wrote:

> Hi Mike,
>
> On Thu, Jul 22, 2010 at 7:24 AM, Mike Solomon <address@hidden> wrote:
> > Hey all,
> >     I'm almost finished w/ a vector-graphic-spanner project I've been
> > working on in Lilypond (that I'm planning on using during the International
> > Composers Pyramid in Kent tomorrow...crosses fingers...), and to make it
> > work 100%, I have to make it so that the Y-extent of the spanner is
> > correctly taken into account every time the spanner breaks lines.  The
> > problem is that sometimes this extent is factored into the layout, and
> > sometimes it is disregarded.  You can see this on:
> >
> > http://www.apollinemike.com/lilypond/vector1.pdf
> > http://www.apollinemike.com/lilypond/vector5.pdf
> >
> > As the amount of code I've produced to make this happen is too big to
> > meaningfully summarize in an email, I'd rather solicit your help by asking:
> > how are spanners' (or just grobs' in general) y-extents found and taken into
> > account in the layout process?  Is there one place where lilypond's
> > vertically-oriented engraver(s) consult(s) grobs/spanners to find their
> > heights, and if so, where?
> That depends on the Y-parent of your grob. If it is a VerticalAlignment, then you should look at Align_interface to see how children of VerticalAlignment are laid out. Otherwise, the Y-offset property of your grob is very important, since it gives the offset between your grob and its Y-parent. How the Y-extent affects the layout depends on what Y-offset is. That is, there are some callbacks for Y-offset that depend on the extent and there are others that don't.
>  
> > For example, how does lilypond know to take a
> > hairpin's height into account for every staff over which said hairpin is
> > split?
> We split the hairpin into multiple hairpins, one for each staff. See Spanner::do_break_processing.
>  
> >   I see some candidates in the source code, but not knowing how any of
> > them really work, I'm not sure if any of the following are promising leads:
> >
> > 1) pure-height: if I created a callback with the correct extent, would that
> > do anything?
> Pure height is used to doing page breaking, but not for the actual layout.
>  
> > 2) axis-group-interface: I am currently not using this interface.  Should I
> > be?  Does that help the correct heights to be factored into the layout?
> Probably not, Y-offset is more important.
>  
> > 3) are there multiple grob parameters that, when set in conjunction, sorta
> > cancel each other out and make lilypond disregard the Y-extent?
> > 4) the unknown...
> >
> > Currently, a slew of pacifier prints using `format' confirm that I'm using
> > the correct extents for the stencil and that the 'Y-extent property is
> > always correct when the print statement is called.  Furthermore, when I
> > print the grob properties (via ly:grob-properties) to the command line, the
> > correctly and incorrectly laid-out grobs all have the same properties.  So,
> > it's hard for me to track down the source of this inconsistent behavior.
> > Any thoughts would be appreciated!
> The current extent and offsets aren't actually stored in ly:grob-properties. For performance reasons, they are in grob->dim_cache_ (only accessible from C++).
>
> Cheers,
> Joe