[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 08:28:30 -0500


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!

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

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


Attachment: scheme-text-spanner-modified.ly
Description: Text Data

reply via email to

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