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
