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
