Add changes entry for Mike's work on skylines.

Add changes entry for Mike's work on skylines.

[janek, 2013-04-10 08:41:33]

list affected grobs"

[janek, 2013-04-10 17:14:22]

typo and clef omission

[Keith, 2013-04-12 06:53:34]

lgtm

https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely
File Documentation/changes.tely (right):

https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#n...
Documentation/changes.tely:156: using an integral-like approach.  This generally
results in more
What is an integral?

https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#n...
Documentation/changes.tely:162: c'4\f a4\f d\f( f)
d'4-.\downbow a4^"r'venu..." c \tempo "T1" e

shows more of the affected grob types

https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#n...
Documentation/changes.tely:178: Affected grobs include @code{Accidentals},
@code{Beams}, @code{Clefs},
What is a grob?

[janek, 2013-04-12 10:23:56]

fixes from keith

[janek, 2013-04-12 10:24:46]

https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely
File Documentation/changes.tely (right):

https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#n...
Documentation/changes.tely:156: using an integral-like approach.  This generally
results in more
On 2013/04/12 06:53:34, Keith wrote:
> What is an integral?

Indeed, many users won't be familiar with this mathematical concept.
I wanted to give a hint about how things work without being too wordy (i.e. that
the objects' outlines are being approximated using simple functions
(https://en.wikipedia.org/wiki/Simple_function - i don't know how to name it
better... "stair function"??)).
Suggestions for better term?

https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#n...
Documentation/changes.tely:162: c'4\f a4\f d\f( f)
On 2013/04/12 06:53:34, Keith wrote:
> d'4-.\downbow a4^"r'venu..." c \tempo "T1" e
> 
> shows more of the affected grob types

good idea.

actually, placement of d4-.\downbow looks like a bug to me.  Its too similar to
square fermata.  Another case where magnetic skylines would help.

https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#n...
Documentation/changes.tely:178: Affected grobs include @code{Accidentals},
@code{Beams}, @code{Clefs},
On 2013/04/12 06:53:34, Keith wrote:
> What is a grob?

Done.

[Keith, 2013-04-13 03:21:23]

On Fri, 12 Apr 2013 03:24:46 -0700, <janek.lilypond@gmail.com> wrote:

>
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#n...
> Documentation/changes.tely:162: c'4\f a4\f d\f( f)
> On 2013/04/12 06:53:34, Keith wrote:
>> d'4-.\downbow a4^"r'venu..." c \tempo "T1" e
>
>> shows more of the affected grob types

> actually, placement of d4-.\downbow looks like a bug to me.  Its too
> similar to square fermata.

All the more reason to include it in the "changes" announcement.  We would not
want this to surprise anyone.

> Another case where magnetic skylines would help.
>

We have something very close with 'skyline-horizontal-padding'.  Do you think
that more people will use it if you change its name to 'skyline-magnetism' ?

[janek, 2013-04-13 13:03:36]

include too snug articulations

[janek, 2013-04-13 13:12:48]

2013/4/13 Keith OHara <k-ohara5a5a@oco.net>:
> On Fri, 12 Apr 2013 03:24:46 -0700, <janek.lilypond@gmail.com> wrote:
>> actually, placement of d4-.\downbow looks like a bug to me.  Its too
>> similar to square fermata.
>
> All the more reason to include it in the "changes" announcement.  We would
> not want this to surprise anyone.

ok

>> Another case where magnetic skylines would help.
>
> We have something very close with 'skyline-horizontal-padding'.  Do you
> think that more people will use it if you change its name to
> 'skyline-magnetism' ?

But horizontal padding is something quite different from magnetic
skylines.  (hmm, maybe i didn't explain it well enough?)
Anyway, i think it would be great to do some work on implementing
magnetic skylines (and other skyline improvements).  I'd gladly help
with that, but i'm pretty sure that i wouldn't be able to do this by
myself - would you be interested in forming a small team to work on
this, perhaps together with Mike?

Janek

[janek, 2013-04-13 21:15:36]

fix silly typo

[MikeSol, 2013-04-16 06:05:42]

https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely
File Documentation/changes.tely (right):

https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely#...
Documentation/changes.tely:153: @item
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.

[dak, 2013-04-16 07:20:59]

On 2013/04/16 06:05:42, MikeSol wrote:
> https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely
> File Documentation/changes.tely (right):
> 
>
https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely#...
> Documentation/changes.tely:153: @item
> 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.

[Trevor Daniels, 2013-04-16 07:40:19]

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.

Trevor

[dak, 2013-04-16 07:51:46]

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.

[Trevor Daniels, 2013-04-16 08:28:40]

On 2013/04/16 07:51:46, dak wrote:
> 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.

So for this particular case we'd need to add predefs
like \vSkylinesOn and \vSkylinesOff, as the override
to turn them on is not quite as straightforward as
turning them off, IIRC.  These would be easy to implement
and document.

[MikeSol, 2013-04-16 08:34:43]

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.

[dak, 2013-04-16 09:59:03]

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.

> We've already had some back-and-forth about text grobs but not much
> else.

Text grobs might be somewhat special, admittedly.

The main problem we have right now is that most of our spacing is an
all-or-nothing game: 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_.

> 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.

So we will likely want to make some huge announcements and use
artificial version numbers like 2.17.95 to get people's attention.

> 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.

And your scores are highly maintenance-intensive in a certain manner.
They are not likely to transfer well to newer versions of LilyPond,
anyway.  For our progression of stable releases, we want a score
without significant numbers of tweaks and overrides (sort of a
"stable" score) to render uniformly better than before.

[mike7, 2013-04-16 10:24:28]

On 16 avr. 2013, at 12:59, dak@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

[wl_gnu.org, 2013-04-16 10:45:52]

> 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.

For my pieces, I always try to avoid overrides and tweaks as much as
possible.  In case something doesn't look OK, I usually submit a bug
report.

IMHO, the very test for lilypond w.r.t. to spacing is piano music from
the romantic era.


    Werner

[janek, 2013-04-16 11:11:03]

2013/4/16  <dak@gnu.org>:
> 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.

This might be impossible.  For example to avoid this problem {
d''4-.\downbow } we'd have to turn off or significantly pad Scripts
skylines, and that will result in wrong placement in other cases.

> 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.

I don't agree.  Too loose spacing is 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.

I wouldn't publish a score which is too loose.  Please look at
https://github.com/janek-warchol/eja-mater-demonstration
and compare the output between 2.16 and 2.17.  2.16 output is not
publication quality, because systems aren't clearly separated; fixing
spacing by hand would be a nightmare.

> 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 _will_happen anyway.  With each and every big feature that
significantly improves something, loads of overrides from user scores
have to be deleted.  You cannot avoid that - we can only try to
minimize this, and with limited success.


2013/4/16  <mtsolo@gmail.com>:
> 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.

probably a good idea.

On behalf of me and Urs Liska i can say that we're using skylines for
our Fried project (100 pages of quite complicated piano music) and
we're very pleased with them.  In fact, we were using them before they
were even pushed to master (using a custom Lily build, which caused us
lots of trouble but i think it was worth it).


2013/4/16  <dak@gnu.org>:
> 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.

maybe..

>> We've already had some back-and-forth about text grobs but not much
>> else.
>
>
> Text grobs might be somewhat special, admittedly.
>
> The main problem we have right now is that most of our spacing is an
> all-or-nothing game: 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.

Indeed.  I've already suggested to use "area spacing" for that, and i
still think it would be a good way to go, but implementing it would
take considerable amount of time.

> 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_.

Area spacing.

>> 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.

Yes, but i'd rather say that things like improving spacing in {
d''4-.\downbow } is a feature request.  Or it means that skylines are
incomplete.  But it's not a bug - the code is doing what it's supposed
to do.  To fix that situation, one has to implement additional
features.

> 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.

I agree except for the fact that i already think its impossible to
tweak defaults to achieve this.

> 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.
>
> So we will likely want to make some huge announcements and use
> artificial version numbers like 2.17.95 to get people's attention.

ok, but i'm afraid that this way we won't release 2.18 in a few
months.  I may be wrong though.

>> 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.
>
> And your scores are highly maintenance-intensive in a certain manner.
> They are not likely to transfer well to newer versions of LilyPond,
> anyway.  For our progression of stable releases, we want a score
> without significant numbers of tweaks and overrides (sort of a
> "stable" score) to render uniformly better than before.

https://github.com/janek-warchol/eja-mater-demonstration
(you can checkout initial commits to get a completely override-free score).

best,
Janek

[Keith, 2013-04-16 17:02:04]

https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely
File Documentation/changes.tely (right):

https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely#...
Documentation/changes.tely:160: #(ly:set-option 'debug-skylines #t)
\override Score.MetronomeMark #'skyline-horizontal-padding = #0.2
\override Score.TextScript #'skyline-horizontal-padding = #0.2
\override Score.Script #'skyline-horizontal-padding = #0.2

%{ LyricText already had this padding.  Other items need it, or old people like
me will need to turn-off skylines so we can read the scores.  
Some other items have a version of this padding that has effect only between the
item and the staff contents, so I'll turn it off here to just show the effect of
one padding. %}

\override Score.TextScript #'outside-staff-horizontal-padding = #0
\override Score.MetronomeMark #'outside-staff-horizontal-padding = #0

[dak, 2013-04-16 19:12:12]

On 2013/04/16 11:11:03, janek wrote:
> 2013/4/16  <dak@gnu.org>:
> > 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.
> 
> This might be impossible.  For example to avoid this problem {
> d''4-.\downbow } we'd have to turn off or significantly pad Scripts
> skylines, and that will result in wrong placement in other cases.

"Wrong placement"?  Seriously?  Can you give any articulation where
you'd get bad behavior for considering just its bounding box?

Most are rather compact anyway, and I don't see how we get an
advantage from being able to sink the dot of a tenuto into a bow
marking.

For inter-script spacing, skylines seem like the entirely wrong thing
to use.  It is conceivable that you can avoid shifting some unrelated
accidental more than a minimum, but that's a harmless problem compared
to scripts creeping into one another.

In general, skylines are mostly nice for grouping _unrelated_
material.  For several things of the _same_ kind, you usually don't
want to shift them into one another.

[mike7, 2013-04-16 19:20:13]

On 16 avr. 2013, at 22:12, dak@gnu.org wrote:

> On 2013/04/16 11:11:03, janek wrote:
>> 2013/4/16  <dak@gnu.org>:
>> > 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.
> 
>> This might be impossible.  For example to avoid this problem {
>> d''4-.\downbow } we'd have to turn off or significantly pad Scripts
>> skylines, and that will result in wrong placement in other cases.
> 
> "Wrong placement"?  Seriously?  Can you give any articulation where
> you'd get bad behavior for considering just its bounding box?

f4->-.
In the bad old days, the staccato was spaced too far from the accent.

Cheers,
MS

[Keith, 2013-04-17 01:03:05]

On Tue, 16 Apr 2013 12:15:23 -0700, mike@mikesolomon.org <mike@mikesolomon.org>
wrote:

>
> On 16 avr. 2013, at 22:12, dak@gnu.org wrote:
>
>> "Wrong placement"?  Seriously?  Can you give any articulation where
>> you'd get bad behavior for considering just its bounding box?
>
> f4->-.
> In the bad old days, the staccato was spaced too far from the accent.

{f'4->-.
  \once\override Script #'skyline-horizontal-padding = #0.2 %{ for a fiddler
withold eyes %}
  f'4->-.
  \once\override Script #'vertical-skylines = #'() %{ just use boxes %}
  f'4->-. }

That is subtle.  We do have individual properties for each type of script, in
scm/scripts.scm.
The downbow and similar could get skyline-horizontal-padding, leaving it zero
for the > accent.

On the other hand, the special thing about > accents is not that we want other
scripts to sidle up alongside, but rather that objects can come close to its
straight lines and still remain visually clear.  More appropriate to reduce the
individually-defined padding in for "accent" in scripts.scm.

[Keith, 2013-04-17 01:03:05]

On Tue, 16 Apr 2013 04:10:32 -0700, Janek Warchoł <janek.lilypond@gmail.com>
wrote:

> 2013/4/16  <dak@gnu.org>:
>> 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.
>
> This might be impossible.  For example to avoid this problem {
> d''4-.\downbow } we'd have to turn off or significantly pad Scripts
> skylines, and that will result in wrong placement in other cases.

>> 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.
>
> I agree except for the fact that i already think its impossible to
> tweak defaults to achieve this.

Then let's un-tweak the defaults for Lyrics.  Sure, some padding helped in your
"Tota pulchra" but it might result in wrong placement in other cases, so we
should remove it:

\new ChoirStaff <<
   \new Lyrics = "s"
   \new Staff = "staff" <<
     \new Voice = "s"  \transpose c c'' { \voiceOne d4 d }
     \new Voice = "a"  \transpose c c' { \voiceTwo d4 d } >>
   \new Lyrics = "s" \with { alignAboveContext = "staff" }
   \context Lyrics = "s" \lyricsto "s" { Ni }
   \context Lyrics = "a" \lyricsto "a" { j  lli } >>
\layout { \context {\Lyrics
     \override VerticalAxisGroup #'nonstaff-relatedstaff-spacing = #'()
     \override LyricText #'skyline-horizontal-padding = #0 }}

[janek, 2013-04-17 20:40:24]

2013/4/17 Keith OHara <k-ohara5a5a@oco.net>:
> On Tue, 16 Apr 2013 04:10:32 -0700, Janek Warchoł <janek.lilypond@gmail.com>
> wrote:
>
>> 2013/4/16  <dak@gnu.org>:
>>> 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.
>>
>> I agree except for the fact that i already think its impossible to
>> tweak defaults to achieve this.
>
>
> Then let's un-tweak the defaults for Lyrics.  Sure, some padding helped in
> your "Tota pulchra" but it might result in wrong placement in other cases,
> so we should remove it:
>
> \new ChoirStaff <<
>   \new Lyrics = "s"
>   \new Staff = "staff" <<
>     \new Voice = "s"  \transpose c c'' { \voiceOne d4 d }
>     \new Voice = "a"  \transpose c c' { \voiceTwo d4 d } >>
>   \new Lyrics = "s" \with { alignAboveContext = "staff" }
>   \context Lyrics = "s" \lyricsto "s" { Ni }
>   \context Lyrics = "a" \lyricsto "a" { j  lli } >>
> \layout { \context {\Lyrics
>     \override VerticalAxisGroup #'nonstaff-relatedstaff-spacing = #'()
>     \override LyricText #'skyline-horizontal-padding = #0 }}

Well, that's indeed amazingly ugly example.
I apologize if my email sounded unfriedndly and/or disparaging.  I
agree that we need sane defaults for skylines, and i admit that
there's room for improvement from the current state.  I'll report any
problematic skyline case if i encounter one.

all the best,
Janek