Re: TupletBracket.shorten-pair with strange output

[Thomas Morley]

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.

>
> I thought it might be helpful to put the changes into
> input/regression/scheme-text-spanner.ly so you might try it with your
> stencil.  I removed all of the grob creation stuff so this works with
> ordinary TextSpanner.  Strangely, it wouldn't work with the code
> that's in the current regtest, but I just happened to have a rewrite
> around that mimics the C++ original more closely :)  Turns out that
> works.
>
> Best,
> David.

Thanks,
  Harm