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.
Ah, gotchya.
I think the problem that this'd cause is that the overestimation may block lyrics/dynamics/what-have-you from sliding to the left as much as they could.
I can certainly give this a shot, though.
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.
SpanBarStubs only exist in contexts that SpanBars traverse but do not have bar lines (see my e-mail on the subject from this morning - it was in a different thread). So, this wouldn't work unless they were redesigned to be a representation of the span bar in all contexts. The problem I see with going down this road is that it wouldn't solve the problem of bar line overhang when span bars are not present.
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.
And I would even go so far as to say that one shouldn't address multiple issues at once unless absolutely necessary.
But here, I think that we can find one elegant solution that solves everything instead of several separate solutions that cause code and logic duplication.
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.
I'll do my best to separate these out - as I said above, I don't want to do it if it is going to compromise the universality of the solution and/or if it'll require reverting one solution to implement a later one. But, I'll mull over it and see if I can cook something up on my 11 hour plane ride today (uggggghhhhhhhhhhhhh).
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/