lilypond-devel
[Top][All Lists]
Advanced

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

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)


From: k-ohara5a5a
Subject: Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
Date: Thu, 10 Nov 2011 07:04:56 +0000


http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc
File lily/pure-from-neighbor-engraver.cc (right):

http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc#newcode72
lily/pure-from-neighbor-engraver.cc:72: //first, clump pure_relevants
into vectors of grobs that have the same column.
comment update

http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc#newcode93
lily/pure-from-neighbor-engraver.cc:93: to the pure grobs on either
side.
comment update

http://codereview.appspot.com/5323062/diff/53017/lily/span-bar-stub-engraver.cc
File lily/span-bar-stub-engraver.cc (right):

http://codereview.appspot.com/5323062/diff/53017/lily/span-bar-stub-engraver.cc#newcode55
lily/span-bar-stub-engraver.cc:55: // note that this can get out of hand
if there are lots of vertical axis groups...
You are telling me to worry but not telling me what to worry about.
There is one Span_bar_stub_engraver per Staff, and for each of these you
add one grob for each spanbar.  The total number is typically the same
as the number of BarLines, so I do not see what gets "out of hand".

http://codereview.appspot.com/5323062/diff/53017/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/5323062/diff/53017/scm/define-grobs.scm#newcode201
scm/define-grobs.scm:201: (extra-spacing-height .
,pure-from-neighbor-interface::extra-spacing-height)
Now this includes all Items within one bar (usually) on each side.

But extra-spacing-height is used when the tentative staff-spacing is
estimated using boxes around everything in the entire length of each
staff, the so-called full-score-pure-minimum-translations.  They are
minimum in the sense of compressed springs, but not really very minimum
because the bounding boxes are so conservative.

If we know the space allocated to a staff during horizontal spacing (the
ly:axis-group-interface::height, I think) and the goal (for issue 1955)
is to build a wall to block anything on the staff, then why build each
wall to a custom, usually shorter, height.

http://codereview.appspot.com/5323062/diff/53017/scm/define-grobs.scm#newcode1859
scm/define-grobs.scm:1859: (SpanBarStub
I can see these have effect in Lyrics, but not in regular Staves.
Weren't they intended to perform the horizontal spacing functions of
SpanBar ?  They do not affect the skylines of the
NonMusicalPaperColumn.

Here, I add some padding so we can see the PaperColumn outlines, and
remove the BarLines from the PaperColumn outline so we can see more
easily.  I see the vestigial SpanBars at the top of the page (I widened
them to distinguish them) but no SpanBarStub, and nothing even trying to
take up space now that the BarLine is out of the picture.

\layout { \context { \Score
  \override NonMusicalPaperColumn #'stencil =
#ly:separation-item::print
  \override PaperColumn #'stencil = #ly:separation-item::print
  \override NonMusicalPaperColumn #'skyline-vertical-padding = #0.5
  \override BarLine #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \override SpanBar #'extra-spacing-width = #'(-1.0 . 1.0)
 }} #(ly:set-option 'debug-skylines)
\new GrandStaff <<
  \new Staff { dis'''1 | dis'''4 r2. | c''1 }
  \new Staff { e'1 | e'1 | fis'''4 r2. } >>

http://codereview.appspot.com/5323062/



reply via email to

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