Re: Issue 1089 in lilypond: DynamicTextSpanner not printed

[Carl Sorensen]

On 5/28/10 10:31 AM, "Xavier Scheuer" <address@hidden> wrote:

> 2010/5/27 <address@hidden>:
> 
>> Comment #4 on issue 1089 by Carl.D.Sorensen: DynamicTextSpanner not
>>> 
>> I actually don't think that 2.10.33 is correct!  The crescendo is
>> supposed to end on the 2nd note in the measure according to the input
>> code.  But the text spanner goes to at least the 3rd note of the
>> measure, and might be interpreted as going to the 4th.  So, even
>> though 2.10.33 prints cresc., I don't think the output is consistent
>> with the input.
> 
> Hi Carl!
> 
> I'm sorry but I don't totally agree.

I think there are two questions here, and perhaps we agree on one and
disagree on the other.

The first question is: Does the 2.10.33 ouptut match what is asked for from
the music, i.e. a text crescendo starting on the first note, and ending on
the second note.  I think we both agree that it does not.  If you think that
the 2.10.33 output matches the input, please explain your reasoning to me.

If you agree that it doesn't match, then having 2.10.33 print it that way
without issuing a warning is wrong -- because we have created output that
doesn't match the input without warning the user about it.

Similarly, the 2.13 functionality is wrong, because we have omitted
something from the output without telling the user about it.

For the record, I don't think either situation is right!

So, what should LilyPond do when it encounters this situation?  I think we
both agree that it *must* emit a warning message.  It's arrived at a
situation where it can't do what is correct.  So it needs to make its best
guess, and tell the user that something has gone wrong.

In my mind, it's probably best to *not* print the cresc. and to omit the
warning, because the user will know (from the output) that something is
missing, and then can go to the log file to figure out why.  On the other
hand, if the cresc. is printed, the user may not notice from the output that
the extent of the text crescendo is too long for the music.  Hence, I think
that not printing is a better failure mode than printing, because it's more
obvious.

On the other hand, I can see that the failure mode of printing provides the
opportunity to use hacks like you've done to get the desired output.  So
there's some value in going ahead and printing.

I don't feel really strongly either way about how LilyPond should fail
gracefully.  I'd accept either mode.  Since you have some files that depend
on having it print, I'm OK with that.

But I don't believe that it is a regression.  A regression means that music
that used to print correctly now doesn't print correctly.  Since it never
printed correctly, it's not a regression.

Note that this doesn't mean it isn't a bug.  It *is* a bug, and should be
fixed.

Thanks,

Carl