Hi Keith, 2014-07-04 9:07 GMT+02:00 Keith OHara <k-ohara5...@oco.net>: > On Wed, 02 Jul 2014 23:56:20 -0700, <janek.lilyp...@gmail.com> wrote: > >>> you should try >>> to make the change consistently everywhere ? >> >> Yes, that's what i'm aiming for. However, as you remember, some of >> these changes produce unwanted side-effects > > I remember you said there were side effects, but you did not until now > say what they were.
I apologize - i mistakenly thought you saw the regtest results back then. Now i realize that you couldn't have seen them. > You say you want ideal spacing to be at least as large as the required > 'rod' that prevents collisions, if the collisions involve accidentals, > >> 0.3 is needed to "slow down" approaching min_distance_, for example in >> beam-rest-extreme.ly - because of the accidentals and suspended notes, >> the min_distance_ is bigger than distance_, which means that even for >> "natural" (ragged-right) spacing the springs would be set to the min >> distance (making the accidentals touch previous notes). We want to add >> some space [to the ideal distance_ -KOH], so that the accidentals >> willtouch previous notes only when there is a significant compressing force. > > but not if the note-columns are wide due to lyrics. > >> Description: >> When objects like lyrics are added to the PaperColumns, LilyPond inserts >> rods between these columns to ensure that the objects won't overlap. >> However, the ideal distance should remain unchanged. > > It is surprising that you distinguish those cases by lengthening the ideal > spacing in merge_springs() but not lengthening the ideal spacing in > set_blocking_force(). That's actually not what i want to do; I apologize for being unclear. I *want* the columns to behave the same way in case of both accidentals and lyrics (and everything else). The desired behaviour is that changing min_distance shouldn't affect ideal distance. Achieving this behaviour when columns are wide due to lyrics is simple: th, but i don't know how to achieve the desired behaviour (i.e. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel