2016-10-23 6:01 GMT+02:00 Paul <p...@paulwmorris.com>:
> On 10/18/2016 12:23 PM, David Kastrup wrote:
>
>> Mark Knoop <m...@opus11.net> writes:
>>>
>>> At 17:05 on 18 Oct 2016, Davide Liessi wrote:
>>>>
>>>> I reproduced the issue with this:
>>>>
>>>> \version "2.19.47"
>>>> \layout { #(layout-set-staff-size 19) }
>>>> { <c'' e'' g''> }
>>>>
>>>> Using #(set-global-staff-size 19) instead works as expected.
>>>> I couldn't find a bug report for this.
>>>> Any ideas?
>>>
>>> Very weird, and certainly a bug. This works as expected also:
>>>
>>> \version "2.19.47"
>>> \layout { #(layout-set-staff-size 19.000000000001) }
>>> { <c'' e'' g''> }
>>
>> Well, _that_ looks like the distance between noteheads is used as a
>> factor for deciding about the arrangement in a manner that is
>> numerically fragile. Like looking whether their distance is smaller
>> than 1.0 staff line distances.
>
>
> Indeed, the distance between note heads is calculated (via calls to
> Staff_symbol_referencer::get_position for each note head) and that distance
> determines whether a note head is moved to the other side of the stem. See
> stem.cc line 553 and following where "dy" is the distance between note
> heads:
> http://git.savannah.gnu.org/cgit/lilypond.git/tree/lily/stem.cc#n553
>
> I tried editing line 565 (the comparison involving "dy" that leads to moving
> a note head) and if you remove the 0.1 "safety margin" this fixes the
> problem (while also breaking the placement for some notes that are only a
> second interval apart). So it does appear to be a mysterious problem of
> numerical fragility.
>
> Some weirdness: if you add \stemUp or \stemDown this fixes the problem, but
> only for chords where the command reverses the default direction of the
> stem. (!?)
>
> Also, the problem (at size 19 at least) seems to only happen for notes at
> certain staff positions, for example on treble staff, notes at E line, A
> space, C space, and F line (symmetrical pattern around center / zero point
> of staff).
>
> That's as far as I've gotten. (Won't have time to do any more for at least
> a week.)
>
> -Paul
I managed to identify the first bad commit:
commit cb6024decee0aafd84baafe34115fc1b2d179df6
Author: David Kastrup <d...@gnu.org>
Date: Thu Nov 13 21:13:12 2014 +0100
Issue 216: ability to change staff line spacing inside a \layout{} block
This uses the staff-space setting from the \layout block (if set) for
determining staff spacing.
It apparently does not help with horizontal spacing, though.
And indeed, reinstantiating the previous state into a build from
latest master fixes the example.
I've no clue why, though.
Cheers,
Harm
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
