Re: fix representation switching from line-position to staff-space (issue 6778050)

[dak]

On 2012/10/30 18:59:49, benko.pal wrote:
> 2012/10/30 David Kastrup <address@hidden>:
> > Benkő Pál <mailto:address@hidden> writes:
> >
> >> 2012/10/27  <address@hidden>:
> >>> On 2012/10/27 20:34:35, benko.pal wrote:
> >>>
> >>>> I want staves with line-positions like (-2 0 2 4) work.
> >>
> >>> Why would somebody specify (-2 0 2 4) with the expectation that
the
> >>> results should be identical to (-3 -1 1 3)?  Why would he not
specify
> >>> (-3 -1 1 3) in the first place then?  How is something "working"
when
> >>> it nullifies what the user is trying to do?
> >>
> >> clefs: when specifying (-4 -2 0 2), you can use \clef alto or
similar
> >> to get a c-clef on the third line.  in other words: when I want to
> >> LilyPond-ize ancient music using four- or six-line staff, the
expected
> >> representation is a standard staff reduced or expanded by a line.
> >
> > And?  Why would looking at the line_count property then yield a
wrong
> > result?  You are specifying a missing line in the line positions,
but
> > the overriden line count would still lead to the same positioning of
> > clefs.  Which would be exactly what was wanted.

> sorry, David, I'm lost.  (-4 -2 0 2) and (-3 -1 1 3) yield different
alto
> clefs,
> I expect that, and that's why I prefer overriding line-positions to
> line-count.

With all the line_count changes, we have basically two use cases.

a) Things that depend on a particular position of each line.  Those
include collision avoidance, micro-alignment to staff or ledger lines,
basically pretty much every use case that would equally well hold for
ledger lines as it would for "regular" lines.

b) positioning relative to an entire Staff.  This includes the
positioning of clefs, positioning of keys, positioning of things like
the divisio maior.

In case of the divisio maior, actually both seem relevant: one would
position according to b) and then might need to slightly adjust ends
in case they hit actual stafflines in a bad way.


What I am arguing is that it is a _mistake_ for use case b) to
actually look at the position of each single staff line.  Just using
line-count rather than essentially
(if (null? line-positions) line-count (length line-positions))
would make things much more predictable.

Particularly in the case if irregularly spaced stafflines, it becomes
impossible for the user to get a predictable positioning of elements
in case he does not want to go with whatever LilyPond picks for him.

> > I really have a hard time seeing just _what_ improvements we get
over
> > the 2.14 behavior.  Is there any _real_ _existing_ problem that now
> > works better than before?

> I never use divisioMaior, so can't speak about that.
> I had real existing problems with rests which launched
> me on this crusade against line_count a year ago.

Rests are "case a)".  That's different: of course things combining
visually with actual lines need to look at the actual lines.  No issue
with that.

> time signatures don't work the 2.14 way, as you admitted in
> http://code.google.com/p/lilypond/issues/detail?id=2783#c35

We settled on "no shift at all" which was essentially the 2.14 way for
most use cases.  The 2.14 way for most use cases was basically
established by two bugs/design errors cancelling each other, and when
one got handled in 2.15, the other surfaced.


https://codereview.appspot.com/6778050/