Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley  wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik :
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley  
>> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn :


 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.

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[Thomas Morley]

2017-04-10 16:08 GMT+02:00 David Nalesnik :
> On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley  
> wrote:
>> 2017-04-10 15:28 GMT+02:00 David Nalesnik :
>>> Harm,
>>>
>>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley  
>>> wrote:
 Hi Malte,

 this is offtopic:

 2017-04-09 22:48 GMT+02:00 Malte Meyn :
>
>
> 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
> }

Aaargh, I really thought I checked this...

Thanks,
  Harm

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley  wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik :
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley  
>> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn :


 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

Re: TupletBracket.shorten-pair with strange output

[Thomas Morley]

2017-04-10 15:28 GMT+02:00 David Nalesnik :
> Harm,
>
> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley  
> wrote:
>> Hi Malte,
>>
>> this is offtopic:
>>
>> 2017-04-09 22:48 GMT+02:00 Malte Meyn :
>>>
>>>
>>> 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

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[Thomas Morley]

Hi Malte,

this is offtopic:

2017-04-09 22:48 GMT+02:00 Malte Meyn :
>
>
> 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.

Cheers,
  Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[Malte Meyn]

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 end.

Maybe this is what you are looking for?:

\override TupletBracket.shorten-pair = #'(2.5 . 2.5)
\override TupletBracket.X-offset = 2.5

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

Harm,

On Sun, Apr 9, 2017 at 1:53 PM, Thomas Morley  wrote:
> The following gives strange output, see attached.
>
> \version "2.19.58"
>
> {
> \override TupletBracket.shorten-pair = #'(10 . 0)
> \tuplet 1/1 {
> c'1 c'1
> }
> }
>
> I would have expected the whole bracket to be (much) smaller, instead
> only the part of the bracket left from TupletNumber is affected.
>

This behavior is ugly but expected.  You're requesting that the left
end of the bracket be moved 10 staff-spaces to the right and the right
end be moved 0 ss.

The way to shorten the bracket would be something like:

 \override TupletBracket.shorten-pair = #'(2 . 2)

Maybe there should be a cap on the amount that a bracket can be
shortened to prevent the inversion in your example?  The bracket
either won't shorten any more or that part of it disappears?

HTH,
David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond