On 16 avr. 2013, at 12:59, d...@gnu.org wrote:

> On 2013/04/16 08:34:43, MikeSol wrote:
>> On 2013/04/16 07:51:46, dak wrote:
>> >
>> > I hate it when I get last-minute realizations.  Here is another
>> > thing we need to do for the stable release: go through all
>> > problems of the "too snug" kind and work out defaults that avoid
>> > them.  It's ok to tell people in our documentation how to get
>> > stuff move closer in case of necessity, but if we aren't talking
>> > about running text and similar things, looser spacing than
>> > necessary is _not_ a bug.
>> >
>> > Closer spacing than appropriate _is_ a bug.  One can publish a
>> > score with loose spacing, but one can't publish a score where
>> > things are sitting on each other.
>> >
>> > So for a stable release, we need conservative settings.  Settings
>> > that won't _force_ people to pepper their sources with overrides
>> > and tweaks just to throw them all out again when the next version
>> > arrives.
> 
>> This is a great time to ping the user list.  People who have been
>> using the development version for a while now have had a chance to
>> get used to scores with this spacing, and if they have anything that
>> they consider "too tight", then we can use simple skylines for those
>> things.
> 
> Actually, I'd very much prefer if we can make do with larger and/or
> different defaults for padding.  Throwing away skylines is a drastic
> measure.  Admittedly, one providing continuity with previous stable
> releases, but I think we still should try first working with
> parameterizing the new code differently before switching it off,
> providing a less uniform (though in some aspects more
> "backward-compatible") experience.

Didn't think of that...this is a better idea.

> 
>> We've already had some back-and-forth about text grobs but not much
>> else.
> 
> Text grobs might be somewhat special, admittedly.
> 

Agreed.

> The main problem we have right now is that most of our spacing is an
> all-or-nothing game:

Agreed.

> it does not figure in _benefits_ of tighter
> spacing like closing large white gaps separating _related_ items, or
> fitting additional systems in, or maintaining consistent distance
> between systems.  Basically one wants to typeset the score with
> _really_ tight skyline-based spacing first, and then let it "relax"
> into a state where skylines are increasingly padded as long as this
> does not cause major gaps or other problems, so that the tight spacing
> is retained only for those situations where it actually makes _sense_.
> 

Agreed, but now you're talking about padding being a spring instead of a 
number, which is a cool idea but LilyPond is waaaaayy far away from that being 
possible.  Vertical spacing is controlled by springs at a marco level in 
page-layout-problem but implementing this at a micro level would take probably 
someone working full time for a year.

>> I think it is a percentage game, more than anything else.  Meaning
>> "what percent of users need to consider spacing too close before it
>> is inappropriate as a default."  If 90% like the new spacing and 10%
>> think it is too close,
> 
> You can't make bugs go away by a vote of confidence.  And that is a
> red herring anyway since nobody suggested switching off the skyline
> code.  It would not make sense to keep the associated code complexity
> while switching the code off.
> 
> So what we need is not a vote.  What we need is as much feedback as we
> can get about cases considered problematic, and we need to see whether
> we can change defaults in a way where they cease being a problem, at
> least to the degree where people will not bother fiddling with
> overrides in order to get rid of them.
> 
> So we need feedback from the heavy hitters, and we have annoyingly few
> of them I know about.  Kieren is one.  I don't know how many tweaks
> there are in Valentin's opera, but that might be another opportunity.
> You would be one, except that your kind of scores require oodles of
> overrides and tweaks anyway so they escape your notice.  People
> maintaining a large corpus of music would be relevant, but Mutopia is
> close to dead regarding its feedback with us, and more active
> score-maintaining sites like Scorio or Philomelos have not really
> moved onto even the 2.16 train (at least regarding last year's news).
> Other projects using LilyPond as backend might also be relevant:
> Denemo comes to mind.

We should hit up Jay: https://github.com/horndude77/open-scores. He'd have a 
good sense of this.

Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to