As always, many thanks for your comments!
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.
On 2011/11/10 07:04:56, Keith wrote:
comment update
Done.
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.
On 2011/11/10 07:04:56, Keith wrote:
comment update
Done.
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...
On 2011/11/10 07:04:56, Keith wrote:
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".
You're right - removed.
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)
On 2011/11/10 07:04:56, Keith wrote:
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.
Because the wall needs to extend places where span bars don't, namely
above and below the staff. And, as we've said before, there can be
holes in the wall. One strategy is to create multiple span bars for one
column depending on where these holes are (this would make overrides
more difficult, but there are ways to get around it that could work not
unlike glissando-index). However, this does not fix the fundamental
problem of how to deal with grobs that span bars would never hit (i.e.
accidentals) but that shouldn't hang over barlines, time signatures,
clefs, etc.
So, using your metaphor of building a wall, I think that the idea of a
custom wall is more tractable - it both allows for holes
(span-bar-allow-span-bar.ly) and allows for the blocking power of the
wall to kick in where it is not visibly present (i.e. the scenario with
accidentals described above).
The quick fix is obviously to revert the patch, but I think we are close
with this, and as I've said several times before, if a rule in
typesetting is that no objects to the right of object X should ever pass
over or under object X, it makes sense that object X's height, in some
way, be estimated from the neighbors that it is supposed to block.
http://codereview.appspot.com/5323062/diff/53017/scm/define-grobs.scm#newcode1859
scm/define-grobs.scm:1859: (SpanBarStub
On 2011/11/10 07:04:56, Keith wrote:
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. } >>
The Span_bar_stub engraver exists only in the Lyrics context.
It is intended to perform the horizontal spacing functions of SpanBar in
vertical axis groups that SpanBars traverse and that are supposed to be
effected by SpanBars but do not have BarLines. With respect to your
example above, Staves would not need them, as they have BarLines. If
you add a Bar_line_engraver to a Lyrics context, you should remove the
Span_bar_engraver.
If BarLines are out of the picture but you want them to take up space as
they did before, it seems like BarLine #'transparent is the way to go.
http://codereview.appspot.com/5323062/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
