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

[k-ohara5a5a]

On 2011/11/10 14:51:22, MikeSol wrote:

> > 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.

To fix issue 1955, they do need that, but I thought every wall on a
given staff could be the same height, specifically the height
tentatively allocated to the staff and its contents during horizontal
spacing.

I was talking about custom heights for every bar along the Staff, rather
than customizing different heights for different staves.

> 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).

Well, if we \once\override Score.SpanBar that should affect the whole
column; while \override Staff.SpanBar{Stub} could affect just one staff.

> 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.


You do not need to address multiple issues at one.

If SpanBars have space reserved where and only where they print, issue
910 would be solved.

If BarLines and KeySignatures later receive extra-spacing-height to
prevent accidentals from hanging over, issue 1955 would be solved.

Separation has the advantage that, should there be an exception to the
rules exemplified by either of these issues, a user can override one
rule and keep the other.


> 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).


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