First stab at getting bar extents right.

First stab at getting bar extents right.

[MikeSol, 2011-10-05 16:16:33]

Hey all,

I'm trying to use my new pure-from-neighbor functions to get bar extents right. 
Currently, barlines are able to block ledger lines from trailing over because of
extra height added to the horizontal skylines in NonMusicalPaperColumn. 
However, they do not block accidentals hanging over, and furthermore, this extra
height blocks some lyrics but not others.

The pure height of barlines should correspond to the height of neighboring grobs
in the VerticalAlignment, allowing for lyrics to pass under the barlines and for
accidentals to always be to the right of a bar.

However, this patch fails on two important counts:

1) It allows lyrics to recede all the way back to the StaffStartBar (see
span-bar-allow-span-bar.ly).
2) It doesn't play nicely with loose columns for some reason (see
spacing-folded-clef-3.ly ... not nice).

So, I'm a bit stuck and could use some help.  Any pointers would be much
obliged!

Cheers,
MS

[mike_apollinemike.com, 2011-10-05 17:57:04]

On Oct 5, 2011, at 6:16 PM, mtsolo@gmail.com wrote:

> Reviewers: ,
> 
> Message:
> Hey all,
> 
> I'm trying to use my new pure-from-neighbor functions to get bar extents
> right.  Currently, barlines are able to block ledger lines from trailing
> over because of extra height added to the horizontal skylines in
> NonMusicalPaperColumn.  However, they do not block accidentals hanging
> over, and furthermore, this extra height blocks some lyrics but not
> others.
> 
> The pure height of barlines should correspond to the height of
> neighboring grobs in the VerticalAlignment, allowing for lyrics to pass
> under the barlines and for accidentals to always be to the right of a
> bar.
> 
> However, this patch fails on two important counts:
> 
> 1) It allows lyrics to recede all the way back to the StaffStartBar (see
> span-bar-allow-span-bar.ly).
> 2) It doesn't play nicely with loose columns for some reason (see
> spacing-folded-clef-3.ly ... not nice).
> 
> So, I'm a bit stuck and could use some help.  Any pointers would be much
> obliged!
> 
> Cheers,
> MS
> 

A bit more research for the non-feint-of-heart (Keith - your input would be
greatly appreciated!).

I believe that the problem with lyrics is that they are centered, which means
that they overflow to the left of note columns.  All of the rods & springs
between NonMusicalPaperColumns on the left and PaperColumns on the right are
attached to the leftmost note-head of the right PaperColumn (I think).  Thus, a
long lyric will exceed the ideal and minimum distance of springs as well as the
rods, going right up to the limit of the NonMusicalPaperColumn to the left.  I'm
thinking of trying to create a rod in Staff_spacing::get_staff_spacing (or
whatever it's called...) that extends from the right edge of the
NonMusicalPaperColumn to the left-most note head of the right PaperColumn, but I
don't know if this is the right way of going about it.  Any thoughts?

Cheers,
MS

[Graham Percival, 2011-10-05 18:09:47]

On Wed, Oct 05, 2011 at 07:56:55PM +0200, mike@apollinemike.com wrote:
> A bit more research for the non-feint-of-heart

My heart is terribly clumsy; I can't distract or mislead anybody.

Cheers,
- Graham

[pkx166h, 2011-10-06 19:33:45]

Passes Make, reg check gives me too much to attach as separate pngs. Attached
zipped output here 

http://code.google.com/p/lilypond/issues/detail?id=1955#c2

graphviz.log gives me

--snip--
@ -14,9 +14,9 @@
 Writing graph `#f'...digraph G {
 rankdir="LR"
 node [shape=rectangle]
-41 [label="caching Stem.stencil\n# -> #"]
-40 [label="caching LedgerLineSpanner.stencil\n# -> #"]
-39 [label="caching VerticalAxisGroup.stencil\n# -> #f"]
+41 [label="caching LedgerLineSpanner.stencil\n# -> #"]
+40 [label="caching VerticalAxisGroup.stencil\n# -> #f"]
+39 [label="caching Stem.stencil\n# -> #"]
 38 [label="caching StaffSymbol.stencil\n# -> #"]
 37 [label="caching Stem.Y-extent\n# -> (-2.812186 . 0.5)"]
 36 [label="caching Stem.length\n# -> 6.624372"]
@@ -56,7 +56,7 @@
 2 [label="NoteHead\n/home/jlowe/lilypond-git/lily/engraver.cc:60\ncause <- # 41
+37 -> 39
 36 -> 37
 35 -> 36
 34 -> 35
--snip--

Not sure if that is good or bad.

and input/regression/page-breaking-good-estimation.log

gives me

--snip--

12 +3,12 @@
 Interpreting music... 
 Preprocessing graphical objects...
 Finding the ideal number of pages...
-Fitting music on 1 page...
+Fitting music on 1 or 2 pages...
 Drawing systems...
-warning: cannot fit music on page: ragged-spacing was requested, but page was
compressed
 Writing header field `texidoc' to
`/home/jlowe/lilypond-git/build/out/lybook-testdb/58/lily-f9565ccd.texidoc'...
 Layout output to
`/home/jlowe/lilypond-git/build/out/lybook-testdb/58/lily-f9565ccd.eps'...
 Layout output to
`/home/jlowe/lilypond-git/build/out/lybook-testdb/58/lily-f9565ccd-1.eps'...
+Layout output to
`/home/jlowe/lilypond-git/build/out/lybook-testdb/58/lily-f9565ccd-2.eps'...
 Writing
/home/jlowe/lilypond-git/build/out/lybook-testdb/58/lily-f9565ccd-systems.texi...
 Writing
/home/jlowe/lilypond-git/build/out/lybook-testdb/58/lily-f9565ccd-systems.tex...
 Writing
/home/jlowe/lilypond-git/build/out/lybook-testdb/58/lily-f9565ccd-systems.count...

--snip--

James

[Keith, 2011-10-07 04:17:11]

On 2011/10/05 16:16:33, MikeSol wrote:
> 2) It doesn't play nicely with loose columns for some reason (see
> spacing-folded-clef-3.ly ... not nice).

Before I implemented skyline-vertical-padding, clefs had an extra-spacing-height
to prevent this, and a couple years before that, there was a hard-coded value
that had the same effect.

The reason I added skyline-vertical-padding was that many individual types of
glyphs needed some vertical padding for the same reason.

Your patch removes the only use of skyline-vertical-padding, so just revert the
whole of 5532fc79, and make sure the individual grobs get the spacing rules they
need for issues 1229 and 1120 and the regtests.

[Keith, 2011-10-07 04:28:38]

// First stab at getting bar extents right.

Now, the bar extents are right already.
They correspond to the extend of the bar as printed.
For some reason, having the extents correct was 
important enough to Pál that he made 51494aa2.

You want the bar to have influence beyond its visible extent, so that
accidentals do not cross over.
That is usually done with extra-spacing-height (for note spacing) or some kind
of padding.

Customize extra-spacing-height instead of extent.

[Keith, 2011-10-07 06:02:14]

On 2011/10/07 04:17:11, Keith wrote:
> Your patch removes the only use of skyline-vertical-padding, 

Oops.  I lied.  There is vertical-padding on NoteColumns too.
So its patch 6d751144 that want to partially revert -- probably just the
define-grobs.scm part.  The C++ changes should stay because that fixed a bug
causing a sneaky asymmetry in the horizontal skylines.

[mike_apollinemike.com, 2011-10-07 06:46:05]

On Oct 7, 2011, at 6:28 AM, k-ohara5a5a@oco.net wrote:

> // First stab at getting bar extents right.
> 
> Now, the bar extents are right already.
> They correspond to the extend of the bar as printed.
> For some reason, having the extents correct was
> important enough to Pál that he made 51494aa2.
> 
> You want the bar to have influence beyond its visible extent, so that
> accidentals do not cross over.
> That is usually done with extra-spacing-height (for note spacing) or
> some kind of padding.
> 
> Customize extra-spacing-height instead of extent.

This I can do.

And in response to your comment about what the patch is trying to do, you're
right.  It exists to let grobs that should spill over/under barlines (lyrics,
for example) spill over whereas other grobs that shouldn't (like accidentals)
stay within the bar.

Cheers,
MS