bug-lilypond
[Top][All Lists]
Advanced

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

Re: Fw: collision between MMR and key signature


From: Keith OHara
Subject: Re: Fw: collision between MMR and key signature
Date: Fri, 21 Jan 2011 23:55:02 -0800
User-agent: Opera Mail/11.00 (Win32)

On Fri, 14 Jan 2011 13:25:23 -0800, Neil Puttock <address@hidden> wrote:

Clefs are taken into account (shown by the yellow-blue skyline pair)
when calculating horizontal skylines for NonMusicalPaperColumn,
whereas key signatures are completely ignored.

We can ensure KeySignature is accounted for by adding it to
`pure-print-callbacks'.


Now I sort of know what you are talking about.
Sometimes the KeySignature has not yet had its extent calculated at the time it 
is consulted regarding note spacing.  I can see the collision between key 
signature and notes as well :

\version "2.12.3"
<< \new Staff {
   f' f' f' f'
   \key des\major
   f'8 f'8 f'4 f'2
   }
   \new Staff {
   f'1  % R1 % replace note with R1 to observe problem in 2.13.46
   f'1
   } >>
\layout {
 \context {
  \Score
  \override KeySignature #'extra-spacing-height = #'(+0.1 . -0.1)
  \override NonMusicalPaperColumn #'stencil = #ly:separation-item::print
  \override PaperColumn #'stencil = #ly:separation-item::print
}} #(ly:set-option 'debug-skylines)

where the negative extra-spacing-height is just to make this observable 
regardless of which issue 1120 patches are in place. If the missing extent is a 
sign of some deeper problem, I'll help chase that.  If it is just a race 
condition, then putting key-signature on the pure-print-callbacks list did work 
to give proper space to the key signature in every case I tried.

From comments to the tracker item:

Carl > If you revert the patch [ee0488] for 1120, you're setting the default to 
0.1.
Carl > If you keep the patch[ee0488], you're setting it to zero.

If the default is zero, then zero-extent items that do not explicitly specify 
any extra-spacing-height will be left out of the skylines for note-spacing.  
Zero-extent items were probably meant to be left out.  I know it annoys me when 
the invisible zero-extent LeftEdge pushes my notes away from a barline.

Supposing (1) we fix 1120 (lyrics inappropriately space notes) by letting note 
columsn always slide over LyricText, with negative extra-spacing-height or 
otherwise.  Then we have freedom to put extra-spacing-height on individual 
grobs as they need it, without the constraint that I earlier believed, of no 
extra-spacing-height allowed on anything that might touch lyrics.

Supposing (2) one way or another KeySignature gets its extent computed before 
it is needed.

Then having a default of zero does seem to make sense.  There will probably be 
a little re-tweaking involved afterwards.

then the constraint




reply via email to

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