Comment #9 on issue 2783 by address@hidden: wrong placement of
timesignature
http://code.google.com/p/lilypond/issues/detail?id=2783
ok, I actually use centre-of-staff-range, i.e. (min + max) / 2, so all of
(-4 4) (-4 2.5 3 3.5 4) (-4 -2 0 2 4) has centre 0.
well, yes, but the benefit is marginal as generally there's no time
signature
within a temporary extension.
I know; my claim is that existing 14th century 4-line staves correspond
not to
\override #'line-count = #4
but to
\override #'line-positions = #'(-2 0 2 4) % (-4 -2 0 2)
I base that claim on clefs (generally c-clefs), which are invariably
on a line,
never in a space. you may say that a clef is anchored to the staff which
I just destroyed with the \override, but I see a clef anchored to a
line of the
theoretically infinite staff of which only a finite segment is shown.
actually that's why I tried to come up with solutions that do not favour
overriding line-count over overriding line-positions.
I agree; incidentally both of my suggested defaults evaluate to 0 in
this case.
the original report has the case (-4 4) which I see rather like the
dot placement of the repeat sign: if a space in the middle of the
staff can
hold the whole time signature, put the whole thing there. (now _that_
does
make prediction harder, but if it corresponds to real world usage, I'm
happy
to implement it.)
consider it whining. to put it otherwise: I sometimes feel myself, a
user
submitting patches, regarded as a second-class citizen compared to one
submitting bug reports and feature requests, though I really take care to
create patches that do not favour my pet projects over all the scores
I know,
including regtests (even if I consider some of them impractical).
remember that my first patch to issue 2533 was reverted (quite
abruptly to me).
at that time it hurt me that that single user reporting issue 2648 was
more important than me (i.e. such a fix was chosen that unfixes my
problem),
but I also conceded that his case is general and important enough,
I've seen it
in several scores, so I worked on a fix that addresses his concerns too.
in this case I'd like to see more data that reverting or modifying
that commit
is better than suggesting to the reporter to override Y-offset.
there's a tradeoff between "predictable solution" and "have to override".
centre-of-staff is almost as easily predicted as 0, and needs no
override in
all the cases I know, including the original one in this thread.