On 2012/10/30 18:59:49, benko.pal wrote:
2012/10/30 David Kastrup <d...@gnu.org>: > Benkő Pál <mailto:benko....@gmail.com> writes: > >> 2012/10/27 <d...@gnu.org>: >>> 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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
