lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.17.1 regtests


From: David Kastrup
Subject: Re: 2.17.1 regtests
Date: Thu, 30 Aug 2012 11:27:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Janek Warchoł <address@hidden> writes:

> On Thu, Aug 30, 2012 at 12:44 AM, David Kastrup <address@hidden> wrote:
>> "address@hidden" <address@hidden> writes:
>>
>>> The regtest that worries me most is les-nereides.ly.
>>>
>>> There is a comment starting on line 827 of axis-group-engraver.cc from
>>> Joe (vintage 2008) that describes this scenario. It's just that excess
>>> spacing has always hid it.  It is now the time to tackle it head on,
>>> as w/ the new skyline patch this type of scenario will come up more
>>> often.
>>
>> You appear worried about the slur through the fingerings.  Yes, that is
>> an ugly collision.  But it is "merely" a collision.  Much more worrying
>> in my opinion is that the staffs in the first third of the page are
>> crammed into each other so tightly that it becomes quite hard to guess
>> which of the interleaved material belongs to top and which to bottom
>> system.  This generally looks like a non-existent staff-staff-spacing
>> only kept apart by collision avoidance.
>>
>> We _really_ need a smart padding strategy reducing this effect which is
>> _far_ too pronounced to produce readable scores.
>
> I definitely agree.  Actually, a while ago i have posted an idea of
> how the solution might look like:
> http://www.freeimagehosting.net/tsr21
> and the description
> http://lists.gnu.org/archive/html/lilypond-devel/2012-03/msg00507.html
> I was a bit surprised to see only moderate amount of interest.
> How do you like this "area" approach?

Not all that much.  The examples are simplistic; actually a multi-scale
approach is warranted: you want collision avoidance at the smallest
scale, and clearance at all scales in between, not just at the line
level.

With nereides, one problem actually is that the padding is vertical
padding.  This makes the following line pairs considered as having the
same distance:

-------------------------
-------------------------

\\
 \\
  \\
   \\
    \\
     \\
      \\
       \\
        \\
         \\

And we actually need _more_ clearance horizontally since staff line
direction favors optically distinguishing vertically adjacent elements
from different staffs.  We have a way to pad skylines horizontally, but
I think that the amount needs to be _quite_ more _iff_ we are trying to
determine the spacing between _independent_ staffs.

I think the interstaff horizontal padding values should be moderate
inside of a treble/bass PianoStaff or ChoirStaff (less need for padding
if the staffgroup has a continuity of pitches), higher within an
arbitrary StaffGroup, and even higher between different systems.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]