Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley <address@hidden> wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik <address@hidden>:
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley <address@hidden> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn <address@hidden>:
>>>>
>>>>
>>>> Am 09.04.2017 um 20:53 schrieb Thomas Morley:
>>>>> I would have expected the whole bracket to be (much) smaller, instead
>>>>> only the part of the bracket left from TupletNumber is affected.
>>>>
>>>> How do you expect any sensible output from that? 10 is so much that the
>>>> “left” end of the bracket is right from the right e
>>>
>>> Well, this happens while trying some heavy overrides, shanghaiing other 
>>> grobs.
>>> Sometimes, doing extreme things leads to detecting some weakness...
>>>
>>> I'm attempting to solve the request at
>>> http://lilypond.1069038.n5.nabble.com/Drawing-wavy-line-across-the-bars-tt201843.html
>>> in an automagical manner.
>>>
>>> Look at the attached picture.
>>> The text is the TupletNumber, the wavy line the TupletBracket. ;)
>>> Though, it gives wrong output, if the TupletBracket is not long
>>> enough. Moving the left end via shorten-pair to make room for the text
>>> gives the strange result then.
>>> Probably another property to use? It's still work in progress and it's
>>> still possible I don't get to stable state...
>>> Maybe TupletBracket is the wrong grob anyway and I should try
>>> HorizontalBracket or another Bracket. Looks I can't go for real
>>> spanners, because there ending gives a warning, when I try to let them
>>> print to the real end of a bar _and_ this bar is the last in the
>>> piece.
>>> Which may be a bug of its own:
>>>
>>> {
>>>     c'1\startTextSpan
>>>     \break
>>>     c'1 <>\stopTextSpan
>>> }
>>>
>>> returns:
>>>
>>> atest-53.ly:1095:12: programming error: bounds of this piece aren't 
>>> breakable.
>>>     c'1
>>>            \startTextSpan
>>> atest-53.ly:1095:12: continuing, cross fingers
>>>
>>> The visual output is ok, though.
>>
>> TextSpanner seems like a more natural grob to co-opt!
>
> No doubt.
> Though, I found no way around the issue above. Obviouly I was too lazy
> to look into scheme-text-spanner.ly-code.
>
> Thanks a lot for it.
>
> Meanwhile I've gotten a stable code for the TupletBracket.
> I think I'll post it.
>
> And then look for the TextSpanner...
>
>
>>
>> The text spanner has its bounds set to NoteColumns. (Broken bounds
>> will be set to NonMusicalPaperColumn later.)  In your example, the
>> engraver runs out of NoteColumns and tries to set the right bound to
>> PaperColumn, which apparently doesn't work  I can put a patch for this
>> forward.
>
> That would be great!
> Ofcourse the same happens for the TrillSpanner, maybe other spanners as well.
> No clue whether this can be fixed in one go.
>

Scratch that...  There are times when the bound of a TextSpanner needs
to be set to a PaperColumn.  As for example:

{
  R1\startTextSpan
  R1\stopTextSpan
}

It's just that you will get that programming error when the
PaperColumn is at the very end of the score.  No idea how to fix that.
I do think that the error --  "bounds of this piece aren't breakable"
-- is very obscure and ought to be rewritten.  It's not "piece," as in
"this piece of music I'm typesetting."  Apparently it's saying that
one possibility of segmenting the spanner for line breaks is
impossible.  In this case, it's a little ridiculous, since we're
talking about breaking the spanner at the very end of the score..

David.