Am 30.08.2012 15:05, schrieb [email protected]:
Comment #9 on issue 2783 by [email protected]: 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).
The comparison between users working on patches and bug submitters may
be a bit
harsh, but I think I see the point.
In my opinion, some rather strange (or say: uncommon) areas of what lilypond
is capable in typesetting are difficult to handle for most of the developers
(no pun intended).
Moreover, it is sometimes not very easy to explain in detail the
"philosophy" behind
a patch. At least I sometimes feel very unhappy about being not able to
formulate
my ideas quite well, since my english is not as good as my ideas
(hopefully) are.
On the other hand, reverting is the easiest thing to do when something
just goes
wrong; so I think there is no-one to blaim here; it is just that there
is not enough
time, not enough developers, not enough understanding of what you want
to archieve.
Perhaps it would be better to have the time to exchange ideas first
before reverting
a patch, but still ...
I hope that your experiences are not too frustrating for you. There are
not as many
developers as lilypond deserves, so we need you. And perhaps there will
be some more
time for a quick exchange of ideas when a patch went (partially) wrong
before
reverting it; it may be that the expectations are wrong and the patch is
correct, or
something in between.
Just my 2 ct
Marc
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.
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
