On 18 nov. 2012, at 21:06, Keith OHara <k-ohara5...@oco.net> wrote:
>>>
>>
>> Try running beam-cross-staff-script.ly with my patch and setting
>> NoteColumn.cross-staff to ##f. You'll see that it triggers beam slope
>> calculations before vertical spacing is done on the staves because
>> NoteColumn, which is a support for the script, has its height checked
>> prematurely. This does not happen in current master because NoteColumn is
>> not a support for Scripts.
>>
>> So why did I make NoteColumn a support for Scripts? I use the NoteColumn as
>> a side support object because it combines the width of the note head with
>> the height of the stem. We don't want UP staccatos, for example, getting
>> tucked down to the left of UP stems but they will if skylines are used. So,
>> we use the NoteColumn as the side support.
>>
>
> I suppose that, strictly speaking, NoteColumn can be 'cross-staff=#t, meaning
> "beware; I might move or change shape when staves are spread across the
> page." But, it seems to preserve more information if we can leave the
> 'cross-staff indication specifically on the Stem.
>
> Scripts clearing Stems is already a special case, controlled by
> 'add-stem-support, which has in the past meant "keep this Script clear of the
> end of the Stem and Flag of its parent, even if it could slide alongside."
> Maybe 'add-stem-support could be implemented as "Consider the Script widened
> enough to include a point on the extended line of the Stem, and keep the
> widened Script clear of the Stem."
>
I'm picking up what you're putting down...
What'd be easy is to add something to the effect of :
if (to_boolean (me->get_property ("add-stem-support"))
&& Stem::has_interface (e))
skyline.set_min_height (e->extent (common_y, _Y_AXIS)[dir]);
That's pseudo-code, but do you get the idea? Does that seem reasonable? If
so, I can get rid of all of that note column business in the engravers and then
note column would no longer have to be cross staff.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
