Re: Add changes entry for Mike's work on skylines. (issue 8613043)

[mtsolo]

On 2013/04/16 07:51:46, dak wrote:
> On 2013/04/16 07:40:19, Trevor Daniels wrote:
> > On 2013/04/16 07:20:59, dak wrote:
> > > On 2013/04/16 06:05:42, MikeSol wrote:
> > >> I would add a note that, if there is too-snug spacing
> > >> for an object, setting its vertical skylines to #'()
> > >> will generally restore old behavior.
> > >
> > > I am not really enthused about telling people that,
> > > since "too snug" is a bug and needs to get fixed rather
> > > than worked around.  We'll get a proliferation of
> > > LilyPond sources irretrievably tied into the bugs of
> > > particular versions if we tell people to work around
> > > bugs rather than report them.
> >
> > Indeed.  That is why we do not document bugs or add
> > workarounds to the documentation (with a few exceptions,
> > usually when it is agreed a fix is most unlikely to
> > materialise, e.g. the grace timing problem.)  Bugs (and
> > their workarounds) should be recorded in the Bug DB.

> 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.  We've
already had some back-and-forth about text grobs but not much else.

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, then it is important to do something like Trevor is
talking about that gives them a way out.  However, if it is 50/50, then
it's better to err on the side of conservative.

Anyway, we'll know none of these things without consulting people making
real scores.  I prefer all the spacing improvements in my scores so no
complaints here.  But I'm willing to admit of course that I wouldn't
have done any of this work unless there were some internal motivation
stemming from my own aesthetic preferences.

https://codereview.appspot.com/8613043/