lilypond-devel
[Top][All Lists]
Advanced

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

Re: Set X-parent of TextScript to NoteColumn instead of PaperColumn (iss


From: Keith OHara
Subject: Re: Set X-parent of TextScript to NoteColumn instead of PaperColumn (issue 106640043 by address@hidden)
Date: Sun, 27 Jul 2014 18:17:04 -0700
User-agent: Opera Mail/12.16 (Win32)

On Sun, 27 Jul 2014 09:44:22 -0700, <address@hidden> wrote:

On 2014/07/26 21:36:12, Keith wrote:
On 2014/07/26 06:49:41, janek wrote:
>
>     Setting TextScript.cross-staff property to #f is required to
ensure
>     that there are no collisions between TextScripts and cross-staff
notes:

The concept of a "cross-staff note" seems strange.  It appeared with
the change
for issue 2527 https://codereview.appspot.com/6827072#msg13


Hmm.  Do i see correctly that the patch in
https://codereview.appspot.com/6827072 was then partially reverted with
commit 7891600a5dd421c1f25776ea3b405c64f4f14752 ?

Right.  NoteColumns are no longer cross-staff.
If we mark TextScript.cross-staff=#t it collides with /any/ note.

Cross-staff things are skipped during outside-staff placement
  axis-group-interface.cc:939
(though it seems they could, with more code, be placed relative to their parent 
staff, without being included in the parent staff's skyline).

Most things that go cross-staff use the side-position-interface to avoid 
collisions, but the engraver for TextScripts does not put anything into its 
'support' list so that method has no effect.

I think the example of issue 1300 succeeds only because TextScript is put in a 
ScriptColumn with the accent.  It collides in the stable release if there is no 
accent, or a trill in place of the accent.

define-grob-properties says 'cross-staff' means that the object can change 
shape or move relative to its parent, depending on how staves are spaced on the 
page.   TextScripts do not yet respond to staff-spacing, except when they are 
in a ScriptColumn that knows how to avoid a cross-staff beam, and that case 
seems inconsistent.

Shall i revert commit
2371d6ba3b62d4d6dc349ab50fa0d76eadfba044 for now?

I don't know.   The case of issue 1300 was not a realistic input, and similar 
cases fail in the stable build.  On the other hand, from the tracker issue, it 
looks like your commit doesn't provide us with any improvements.




reply via email to

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