[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: skyline vs. y-aligned-side

From: Joe Neeman
Subject: Re: skyline vs. y-aligned-side
Date: Thu, 25 Jan 2007 21:17:33 +0200

On 1/25/07, Han-Wen Nienhuys <address@hidden> wrote:

Hello Joe,

2 questions

1. do you see any reason to use


for Y-offset callbacks on stuff that uses outside-staff-priority?

It makes certain user-overrides a little easier. Since
outside-staff-priority only ever pushes objects away from the staff,
you could add extra padding to an outside-staff-priority object to
give things a more uniform appearance, for example.

If not: we could scrap that, as well as all the code necessary to
create the side-support-elements information for those grobs.

There are certainly places where that code can be simplified -- I've
even made some changes already in my working copy. There's a bunch of
stuff that's only there to deal with collisions and that can all be

2. it would be cool if it were possible to position several grobs as a
single outline. Right now, we use DynamicLineSpanner to ensure that
all related dynamics stay on one Y position, but I suspect that it
should be possible to use the outside-staff-prority stuff to do that.
Do you think you could pull that off? Of course, the grobs will be marked
so that it is possible to distinguish related  groups of dynamics.

The same holds for piano pedals. If we could do this, this would simplify
dynamics-engraver a lot, and we could scrap piano-pedal-align-engraver.

Sure, I'll give that a try. As far as distinguishing related dynamics
goes, what if each DynamicText (PianoPedal, etc.) just had a pointer
to the next related one? Then you have a lot of flexibility (in the
backend at least) because you can align arbitrary grob types (eg. a
DynamicText with a VoltaBracket).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]