[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TupletBracket.shorten-pair with strange output

From: David Nalesnik
Subject: Re: TupletBracket.shorten-pair with strange output
Date: Mon, 10 Apr 2017 09:08:19 -0500

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.

The to-barline property lets you do what you want without the code
fix, though probably that weird programming error should be fixed

  \override TextSpanner.to-barline = ##t
  c1 <>\stopTextSpan

  \override TrillSpanner.to-barline = ##t
  c1 <>\stopTrillSpan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]