Re: Issue 787 in lilypond: script stack order fails with 2 more notes

[Carl Sorensen]

On 12/2/09 4:56 PM, "Trevor Daniels" <address@hidden> wrote:

> 
> 
> Carl Sorensen wrote Wednesday, December 02, 2009 10:29 PM
>> 
>> In order to do the proper explanation, it seems to me we need to
>> be clear on
>> three things:
>> 
>> 1) Stacking priority depends on outside-staff-priority if it's
>> present
>> 2) If not, it depends on script-priority
>> 3) How to decide if objects have an outside-staff-priority or a
>> script-priority, and what the value of those priorities is, so we
>> can
>> intelligently override things where it's needed.
>> 
>> I'm clear on 1) and 2).  But I'm not clear on 3).
>> 
>> In the NR, I can find 1.3.1 Articulations and ornamentations,
>> which appear
>> to be Script or TextScript objects (I'm not sure how to decide
>> which -- both
>> are cross-referenced to the IR).
>> 
>> In the IR, Scripts have neither a staff-priority nor an
>> outside-staff-priority listed.  But it does list the
>> grob-interface, which
>> has outside-staff-priority property.
>> 
>> Also in the IR, TextScripts have outside-staff-priority of 450 and
>> script-priority of 200.
>> 
>> So \turn must not be a TextScript, and I can't see (from the
>> documentation)
>> that either priority is set for Script objects.
>> 
>> Can you help me figure out where to learn more about this?
> 
> Try LM 4.4 ;)

Very nice!

But I have some concerns about the presentation in the LM of script
priorities.  I'm worried that those tables are unmaintainable.  If the code
changes, the table values will need to be changed manually.  In the NR, that
would be a big no-no; instead we need to point to automatically-generated
documentation that will always have the current value.

> 
> Seriously, we ought to expand that section in
> the LM to mention Script priority, or to point
> to the section in the NR which deals with it.
> Keep me in on this loop and I'll pick up the
> pieces for the LM


I'm going to add something to the NR, and I'll be sure you're in the loop.


Thanks,

Carl