On Nov 10, 2011, at 10:38 AM, k-ohara5...@oco.net wrote: > 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/
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel