On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley <thomasmorle...@gmail.com> wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik <david.nales...@gmail.com>:
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley <thomasmorle...@gmail.com>
>> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn <lilyp...@maltemeyn.de>:
>>>>
>>>>
>>>> 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.
The to-barline property lets you do what you want without the code
fix, though probably that weird programming error should be fixed
anyway!
{
\override TextSpanner.to-barline = ##t
c1\startTextSpan
c1
\break
c1 <>\stopTextSpan
}
{
\override TrillSpanner.to-barline = ##t
c1\startTrillSpan
c1
\break
c1 <>\stopTrillSpan
}
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
