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.
Cheers, MS |