[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
From: |
address@hidden |
Subject: |
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062) |
Date: |
Mon, 31 Oct 2011 22:05:23 +0100 |
On Oct 31, 2011, at 6:18 PM, address@hidden wrote:
> On Oct 31, 2011, at 3:19 PM, Phil Holmes wrote:
>
>>
>> Mike - do you have a Windows machine? And a Windows .exe for your changes?
>> If so, you could run my pixel comparator.
>>
>> --
>> Phil Holmes
>>
>>
>
> Unfortunately, I don't have a Windows machine, nor am I able to make a
> Windows .exe :(
> I'll be able to dig into the TabStaff regtests in a couple days to see why
> they're coming up green.
>
> Cheers,
> MS
Figured it out.
-) TabStaffs tend to make horizontal spacing tighter, as the average spring
between paper columns has an ideal length that is shorter than that of staves
comprised of normal notes.
-) When the default skyline-horizontal-padding for NonMusicalPaperColumns was
#0.6, this tightened spacing was blocked by the left-most NonMusicalPaperColumn.
-) In the current patch, the NonMusicalPaperColumn has no
skyline-horizontal-padding, which means that the spacing is not blocked and can
compress even further.
Whether or not the above scenario is aesthetically desirable or not is, of
course, up for debate. Given that the 0.6 skyline horizontal padding is,
according to the comment above it, only intended to block ledger lines from
overlapping a bar line, I think that this blocking effect it has on horizontal
spacing is an unintended side effect. So, unless anyone has arguments for why
the old behavior should be kept, I think this is an acceptable (and even
desirable) consequence of this patch.
Cheers,
MS
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062),
address@hidden <=