Text spanner shorten-pair

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Text spanner shorten-pair

Andrew Bernard
Do TextSpanners support shorten-pair?

The NR for 2.19.82 says:

shorten-pair (pair of numbers)
The lengths to shorten on both sides a hairpin or text-spanner such as a pedal bracket. Positive values shorten the hairpin or text-spanner, while negative values lengthen it.

This does not work:

\version "2.19.82"

{
  \override TextSpanner.shorten-pair = #'(-3 . 2)
  c''4\startTextSpan
  c''4
  c''
  c''\stopTextSpan
}

What's happening? Did this work in the past?

Andrew


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Text spanner shorten-pair

Aaron Hill
On 2019-01-25 3:36 am, Andrew Bernard wrote:

> Do TextSpanners support shorten-pair?
>
> The NR for 2.19.82 says:
>
> shorten-pair (pair of numbers)
> The lengths to shorten on both sides a hairpin or text-spanner such as
> a
> pedal bracket. Positive values shorten the hairpin or text-spanner,
> while
> negative values lengthen it.

It's not listed under any of the interfaces that TextSpanner supports.  
Instead, it looks like Hairpin, HorizontalBracket, OttavaBracket,
PianoPedalBracket, TupletBracket, and VoltaBracket are the only things
referencing shorten-pair.  And in NEWS.txt there is this comment:

     The ends of hairpins may now be fine-tuned using the ‘shorten-pair’
     grob property.  This previously only affected text-spanners (e.g.
     ‘TupletBracket’ and ‘OttavaBracket’).

That all said, it looks like bound-details.left/right support padding:

   \override TextSpanner.bound-details.left.padding = #-2
   \override TextSpanner.bound-details.right.padding = #-3


-- Aaron Hill

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Text spanner shorten-pair

Andrew Bernard
Hi Aaron,

I know. This then implies the NR is in error. Do we report a bug? [For the reason that being thrown off the scent I spent hours looking all in the interfaces to no avail.]

The padding works. Seems inconsistent to me. Why do we leave TextSpanners out of the group?

Andrew


On Fri, 25 Jan 2019 at 23:32, Aaron Hill <[hidden email]> wrote:
On 2019-01-25 3:36 am, Andrew Bernard wrote:
> Do TextSpanners support shorten-pair?
>
> The NR for 2.19.82 says:
>
> shorten-pair (pair of numbers)
> The lengths to shorten on both sides a hairpin or text-spanner such as
> a
> pedal bracket. Positive values shorten the hairpin or text-spanner,
> while
> negative values lengthen it.

It's not listed under any of the interfaces that TextSpanner supports. 
Instead, it looks like Hairpin, HorizontalBracket, OttavaBracket,
PianoPedalBracket, TupletBracket, and VoltaBracket are the only things
referencing shorten-pair.  And in NEWS.txt there is this comment:

     The ends of hairpins may now be fine-tuned using the ‘shorten-pair’
     grob property.  This previously only affected text-spanners (e.g.
     ‘TupletBracket’ and ‘OttavaBracket’).

That all said, it looks like bound-details.left/right support padding:

   \override TextSpanner.bound-details.left.padding = #-2
   \override TextSpanner.bound-details.right.padding = #-3


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Text spanner shorten-pair

Carl Sorensen-3

 

 

From: Andrew Bernard <[hidden email]>
Date: Friday, January 25, 2019 at 6:21 AM
To: lilypond-user Mailinglist <[hidden email]>
Subject: Re: Text spanner shorten-pair

 

Hi Aaron,

 

I know. This then implies the NR is in error. Do we report a bug? [For the reason that being thrown off the scent I spent hours looking all in the interfaces to no avail.]

 

I think this is absolutely a bug.  It should not say shorten-pair applies to TextSpanners when it does not. 

 

There are three possible solutions I can see:

 

  1. Fix the description of shorten-pair to indicate which spanners it applies to
  2. Create a new interface e.g. shortenable-spanner-interface that contains shorten-pair, and then give that interface to all the grobs that accept shorten-pair (see dynamic-line-spanner-interface for a similar single-property interface).

 

The padding works. Seems inconsistent to me. Why do we leave TextSpanners out of the group?

  1. Add the shorten-pair property to the spanner-interface (or maybe the text-spanner interface) and make sure it works with all of the objects having that interface.

 

My preference right now would probably be #2.

 

I have not made an exhaustive study of this, but my initial thought is that there are two kinds of spanners.

 

Spanner type A goes from one grob to another (e.g. TextSpanner, glissando).  These spanners can be shortened by adding padding, because they will need to move away from the grobs that they connect when the padding is increased.

 

Spanner type B goes from one column to another (e.g. hairpin, pedal bracket).  These spanners don’t have grobs at their ends, so padding will not be effective at shortening them.  Hence the need for another method, as met by the shorten-pair property.

 

One could add the shorten-pair property to the type A spanners, but it’s not necessary to do so to shorten them.

 

I don’t know what I prefer for the long-term solution.  It would take more study and consideration of the pros and cons of each method.

 

Thanks,


Carl

 

 


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Text spanner shorten-pair

Trevor Bača-2
On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen <[hidden email]> wrote:

 

 

From: Andrew Bernard <[hidden email]>
Date: Friday, January 25, 2019 at 6:21 AM
To: lilypond-user Mailinglist <[hidden email]>
Subject: Re: Text spanner shorten-pair

 

Hi Aaron,

 

I know. This then implies the NR is in error. Do we report a bug? [For the reason that being thrown off the scent I spent hours looking all in the interfaces to no avail.]

 

I think this is absolutely a bug.  It should not say shorten-pair applies to TextSpanners when it does not. 

 

There are three possible solutions I can see:

 

  1. Fix the description of shorten-pair to indicate which spanners it applies to
  2. Create a new interface e.g. shortenable-spanner-interface that contains shorten-pair, and then give that interface to all the grobs that accept shorten-pair (see dynamic-line-spanner-interface for a similar single-property interface).

 

The padding works. Seems inconsistent to me. Why do we leave TextSpanners out of the group?

  1. Add the shorten-pair property to the spanner-interface (or maybe the text-spanner interface) and make sure it works with all of the objects having that interface.

 

My preference right now would probably be #2.

 

I have not made an exhaustive study of this, but my initial thought is that there are two kinds of spanners.

 

Spanner type A goes from one grob to another (e.g. TextSpanner, glissando).  These spanners can be shortened by adding padding, because they will need to move away from the grobs that they connect when the padding is increased.

 

Spanner type B goes from one column to another (e.g. hairpin, pedal bracket).  These spanners don’t have grobs at their ends, so padding will not be effective at shortening them.  Hence the need for another method, as met by the shorten-pair property.

 

One could add the shorten-pair property to the type A spanners, but it’s not necessary to do so to shorten them.

 

I don’t know what I prefer for the long-term solution.  It would take more study and consideration of the pros and cons of each method.


Hi Carl, hi Andrew,

Also agreed that this is very much a bug; I've watched beginners get hit by it many times.

Question: why are there two ways to move around the ends of spanners (padding vs. shortening)? I can't think of a reason that's motivated by music notation. Which maybe implies that there's a fourth solution:

4. Collapse shorten-pair into padding (or vice versa), and preserve one (and only one) such property for *ALL* spanners.


Trevor.
 

--

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Text spanner shorten-pair

Carl Sorensen-3

 

 

From: Trevor Bača <[hidden email]>
Date: Tuesday, February 12, 2019 at 3:09 PM
To: Carl Sorensen <[hidden email]>
Cc: Andrew Bernard <[hidden email]>, lilypond-user Mailinglist <[hidden email]>
Subject: Re: Text spanner shorten-pair

 

On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen <[hidden email]> wrote:

 

Question: why are there two ways to move around the ends of spanners (padding vs. shortening)? I can't think of a reason that's motivated by music notation.

 

Padding is a minimum amount of blank space between two pieces of ink on the page.  When a pedal bracket is running into empty space, it doesn’t matter what the padding setting is, because there is no ink for it to move away from.  Padding says “don’t just avoid collisions; leave a minimum amount of empty space in addition to avoiding collisions”.  There’s no collision to avoid between a pedal bracket and its associated note column.

 

Which maybe implies that there's a fourth solution:

 

4. Collapse shorten-pair into padding (or vice versa), and preserve one (and only one) such property for *ALL* spanners.

 

It seems to me that if you are to collapse into a single property, it would need to be shorten-pair, because we already have padding and it doesn’t do what you want if there’s no ink to avoid.   But I haven’t looked at all into how the code would need to change with the spanners that don’t currently have shorten-pair.

 

Thanks,

 

Carl

 


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Text spanner shorten-pair

Trevor Bača-2


On Tue, Feb 12, 2019 at 6:12 PM Carl Sorensen <[hidden email]> wrote:

 

 

From: Trevor Bača <[hidden email]>
Date: Tuesday, February 12, 2019 at 3:09 PM
To: Carl Sorensen <[hidden email]>
Cc: Andrew Bernard <[hidden email]>, lilypond-user Mailinglist <[hidden email]>
Subject: Re: Text spanner shorten-pair

 

On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen <[hidden email]> wrote:

 

Question: why are there two ways to move around the ends of spanners (padding vs. shortening)? I can't think of a reason that's motivated by music notation.

 

Padding is a minimum amount of blank space between two pieces of ink on the page.  When a pedal bracket is running into empty space, it doesn’t matter what the padding setting is, because there is no ink for it to move away from.  Padding says “don’t just avoid collisions; leave a minimum amount of empty space in addition to avoiding collisions”.  There’s no collision to avoid between a pedal bracket and its associated note column.


Ok, wow, this is actually hugely interesting. Thank you so much for the specificity of the first part of the answer: "Padding is a minimum amount of blank space between two pieces of ink on the page." That is actually genuinely new information to me about a small-but-pervasive concept in LilyPond. Right up until just now, I had assumed that padding meant "a minimum amount of blank space between TWO THINGS on the page (whether the things are visible or not)"; we are hugely concerned with the (frequently invisible) start- and stop-anchors of things when engraving objects in score; and I had incorrectly assumed that padding at the edges of, say, a piano pedal bracket would pad between the invisible start-anchor of the bracket (which you described earlier as some flavor of column) and the visible start of the bracket itself. This is apparently not the case.

This probably explains a small part of why I may have found the spacing behavior of piano pedal brackets flakey, to a certain extent, for well over a decade.

So my surprise here (that the Lily concept of "padding" won't pad between the invisible anchors of things that I'm always mentally tracking when I work), makes me think that this surprisingly-restricted (at least to me ;) model of padding is possibly a "mis-model" in the system, or maybe a not-yet-realized possibility for a more complete generalization of what spanners are.

Put another way, why *shouldn't* spanners pad between their anchors, whether those anchors are visible or not? The thing that earlier caught my eye in this thread was when you started to taxonomize spanners: "there's a first group that would include glissandi and text spanners" and "then there's a second group that would include hairpins and piano pedal brackets," etc. And I immediately found that taxonomy surprising; were there realworld (music-notational) criteria motivating the taxonomy? I couldn't come up with any, and now understanding the restricted definition of padding explains why: you knew how Lily is internally defining padding, and so you were taxonomining according to that piece of system implementation. This explains a lot, though I think that maybe the better thing to do is to extend the spanner behaviors (padding, in this case) *to all the spanners*, rather than cladding in iron a distinction (like 'stretchable' / 'paddable' with a stretchable-spanner-interface / paddable-spanner-interface) that might best be argued doesn't exist just by working with the symbols as music notation in the first place.

To be clear, I'm absolutely just thinking aloud here ;) This is *not* a request for any changes anywhere in the system: and the decision of something like "collapse shorten-padding into padding, or vice versa" is going to require a lot more thought, for sure. I just wanted to document what now seems like a fairly fundamental point of understanding in the system that will need to dealt with at some point. Either the complete set of spanner behaviors should increasing be generalized to all the spanners (which is always what seems to be the starting point for threads like these where someone asks "why isn't X property implemented on  Y spanner?") or else we're going to need to document very strongly this important way in which the sense of padding is restricted in Lily.



   


 

 

Which maybe implies that there's a fourth solution:

 

4. Collapse shorten-pair into padding (or vice versa), and preserve one (and only one) such property for *ALL* spanners.

 

It seems to me that if you are to collapse into a single property, it would need to be shorten-pair, because we already have padding and it doesn’t do what you want if there’s no ink to avoid.   But I haven’t looked at all into how the code would need to change with the spanners that don’t currently have shorten-pair.


Thanks again, Carl. This has given me important new information to think about and work with.

Trevor.
 


--

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Text spanner shorten-pair

Carl Sorensen-3

 

 

From: Trevor Bača <[hidden email]>
Date: Wednesday, February 13, 2019 at 6:43 AM
To: Carl Sorensen <[hidden email]>
Cc: Andrew Bernard <[hidden email]>, lilypond-user Mailinglist <[hidden email]>
Subject: Re: Text spanner shorten-pair

 

 

 

On Tue, Feb 12, 2019 at 6:12 PM Carl Sorensen <[hidden email]> wrote:

 

 

From: Trevor Bača <[hidden email]>
Date: Tuesday, February 12, 2019 at 3:09 PM
To: Carl Sorensen <[hidden email]>
Cc: Andrew Bernard <[hidden email]>, lilypond-user Mailinglist <[hidden email]>
Subject: Re: Text spanner shorten-pair

 

On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen <[hidden email]> wrote:

 

Question: why are there two ways to move around the ends of spanners (padding vs. shortening)? I can't think of a reason that's motivated by music notation.

 

Padding is a minimum amount of blank space between two pieces of ink on the page.  When a pedal bracket is running into empty space, it doesn’t matter what the padding setting is, because there is no ink for it to move away from.  Padding says “don’t just avoid collisions; leave a minimum amount of empty space in addition to avoiding collisions”.  There’s no collision to avoid between a pedal bracket and its associated note column.

 

Ok, wow, this is actually hugely interesting. Thank you so much for the specificity of the first part of the answer: "Padding is a minimum amount of blank space between two pieces of ink on the page." That is actually genuinely new information to me about a small-but-pervasive concept in LilyPond. Right up until just now, I had assumed that padding meant "a minimum amount of blank space between TWO THINGS on the page (whether the things are visible or not)"; we are hugely concerned with the (frequently invisible) start- and stop-anchors of things when engraving objects in score; and I had incorrectly assumed that padding at the edges of, say, a piano pedal bracket would pad between the invisible start-anchor of the bracket (which you described earlier as some flavor of column) and the visible start of the bracket itself. This is apparently not the case.

 

I think that I was incorrect in saying “ink on the page”, although that is the intent of padding.  I should have said “between two bounding boxes”.  One way to make spanners respect padding would be to increase the vertical extent of the bounding box (but that comes with a cost of preventing markups from sitting above or below the bounding box.

 

This probably explains a small part of why I may have found the spacing behavior of piano pedal brackets flakey, to a certain extent, for well over a decade.

 

So my surprise here (that the Lily concept of "padding" won't pad between the invisible anchors of things that I'm always mentally tracking when I work), makes me think that this surprisingly-restricted (at least to me ;) model of padding is possibly a "mis-model" in the system, or maybe a not-yet-realized possibility for a more complete generalization of what spanners are.

 

I think that you have hit on an important fundamental that is not properly represented in LilyPond.  Spanners might be properly said to be anchored to note columns *regardless* of whether they have anything in them at a particular vertical location.  Maybe the spacing algorithms for spanners should assume a note-column with infinite vertical extents….

 

 

Thanks for your good thoughts about this.

 

Carl

 


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

A metacomment on Re: Text spanner shorten-pair

David Wright
Can I just point out that, whether you top-post or bottom-post,
it's nearly impossible to follow the conversation in the plain text
version of this post because there's no indication of quoting.

On Wed 13 Feb 2019 at 14:33:39 (+0000), Carl Sorensen wrote:

>
>
> From: Trevor Bača <[hidden email]>
> Date: Wednesday, February 13, 2019 at 6:43 AM
> To: Carl Sorensen <[hidden email]>
> Cc: Andrew Bernard <[hidden email]>, lilypond-user Mailinglist <[hidden email]>
> Subject: Re: Text spanner shorten-pair
>
>
>
> On Tue, Feb 12, 2019 at 6:12 PM Carl Sorensen <[hidden email]<mailto:[hidden email]>> wrote:
>
>
> From: Trevor Bača <[hidden email]<mailto:[hidden email]>>
> Date: Tuesday, February 12, 2019 at 3:09 PM
> To: Carl Sorensen <[hidden email]<mailto:[hidden email]>>
> Cc: Andrew Bernard <[hidden email]<mailto:[hidden email]>>, lilypond-user Mailinglist <[hidden email]<mailto:[hidden email]>>
> Subject: Re: Text spanner shorten-pair
>
> On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen <[hidden email]<mailto:[hidden email]>> wrote:
>
> Question: why are there two ways to move around the ends of spanners (padding vs. shortening)? I can't think of a reason that's motivated by music notation.
>
> Padding is a minimum amount of blank space between two pieces of ink on the page.  When a pedal bracket is running into empty space, it doesn’t matter what the padding setting is, because there is no ink for it to move away from.  Padding says “don’t just avoid collisions; leave a minimum amount of empty space in addition to avoiding collisions”.  There’s no collision to avoid between a pedal bracket and its associated note column.
>
> Ok, wow, this is actually hugely interesting. Thank you so much for the specificity of the first part of the answer: "Padding is a minimum amount of blank space between two pieces of ink on the page." That is actually genuinely new information to me about a small-but-pervasive concept in LilyPond. Right up until just now, I had assumed that padding meant "a minimum amount of blank space between TWO THINGS on the page (whether the things are visible or not)"; we are hugely concerned with the (frequently invisible) start- and stop-anchors of things when engraving objects in score; and I had incorrectly assumed that padding at the edges of, say, a piano pedal bracket would pad between the invisible start-anchor of the bracket (which you described earlier as some flavor of column) and the visible start of the bracket itself. This is apparently not the case.
>
> I think that I was incorrect in saying “ink on the page”, although that is the intent of padding.  I should have said “between two bounding boxes”.  One way to make spanners respect padding would be to increase the vertical extent of the bounding box (but that comes with a cost of preventing markups from sitting above or below the bounding box.
>
> This probably explains a small part of why I may have found the spacing behavior of piano pedal brackets flakey, to a certain extent, for well over a decade.
>
> So my surprise here (that the Lily concept of "padding" won't pad between the invisible anchors of things that I'm always mentally tracking when I work), makes me think that this surprisingly-restricted (at least to me ;) model of padding is possibly a "mis-model" in the system, or maybe a not-yet-realized possibility for a more complete generalization of what spanners are.
>
> I think that you have hit on an important fundamental that is not properly represented in LilyPond.  Spanners might be properly said to be anchored to note columns *regardless* of whether they have anything in them at a particular vertical location.  Maybe the spacing algorithms for spanners should assume a note-column with infinite vertical extents….
>
>
> Thanks for your good thoughts about this.
>
> Carl

Cheers,
David.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Text spanner shorten-pair

Trevor Bača-2
In reply to this post by Carl Sorensen-3


On Wed, Feb 13, 2019 at 8:33 AM Carl Sorensen <[hidden email]> wrote:

 

 

From: Trevor Bača <[hidden email]>
Date: Wednesday, February 13, 2019 at 6:43 AM
To: Carl Sorensen <[hidden email]>
Cc: Andrew Bernard <[hidden email]>, lilypond-user Mailinglist <[hidden email]>
Subject: Re: Text spanner shorten-pair

 

 

 

On Tue, Feb 12, 2019 at 6:12 PM Carl Sorensen <[hidden email]> wrote:

 

 

From: Trevor Bača <[hidden email]>
Date: Tuesday, February 12, 2019 at 3:09 PM
To: Carl Sorensen <[hidden email]>
Cc: Andrew Bernard <[hidden email]>, lilypond-user Mailinglist <[hidden email]>
Subject: Re: Text spanner shorten-pair

 

On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen <[hidden email]> wrote:

 

Question: why are there two ways to move around the ends of spanners (padding vs. shortening)? I can't think of a reason that's motivated by music notation.

 

Padding is a minimum amount of blank space between two pieces of ink on the page.  When a pedal bracket is running into empty space, it doesn’t matter what the padding setting is, because there is no ink for it to move away from.  Padding says “don’t just avoid collisions; leave a minimum amount of empty space in addition to avoiding collisions”.  There’s no collision to avoid between a pedal bracket and its associated note column.

 

Ok, wow, this is actually hugely interesting. Thank you so much for the specificity of the first part of the answer: "Padding is a minimum amount of blank space between two pieces of ink on the page." That is actually genuinely new information to me about a small-but-pervasive concept in LilyPond. Right up until just now, I had assumed that padding meant "a minimum amount of blank space between TWO THINGS on the page (whether the things are visible or not)"; we are hugely concerned with the (frequently invisible) start- and stop-anchors of things when engraving objects in score; and I had incorrectly assumed that padding at the edges of, say, a piano pedal bracket would pad between the invisible start-anchor of the bracket (which you described earlier as some flavor of column) and the visible start of the bracket itself. This is apparently not the case.

 

I think that I was incorrect in saying “ink on the page”, although that is the intent of padding.  I should have said “between two bounding boxes”.  One way to make spanners respect padding would be to increase the vertical extent of the bounding box (but that comes with a cost of preventing markups from sitting above or below the bounding box.

 

This probably explains a small part of why I may have found the spacing behavior of piano pedal brackets flakey, to a certain extent, for well over a decade.

 

So my surprise here (that the Lily concept of "padding" won't pad between the invisible anchors of things that I'm always mentally tracking when I work), makes me think that this surprisingly-restricted (at least to me ;) model of padding is possibly a "mis-model" in the system, or maybe a not-yet-realized possibility for a more complete generalization of what spanners are.

 

I think that you have hit on an important fundamental that is not properly represented in LilyPond.  Spanners might be properly said to be anchored to note columns *regardless* of whether they have anything in them at a particular vertical location.  Maybe the spacing algorithms for spanners should assume a note-column with infinite vertical extents….


This once again comes an extremely clarifying point; thank you, again, for taking the time specify the constraints on positioning behavior so explicitly. It will take more time to think through what this means ...

Perhaps off topic, but I have a years-old question you might be able to answer: what is it that caused the implementation of text spanners (probably all spanners, actually) to exclude the availability of "length-1" spanners?

By "length-1 spanner" I mean a text spanner that encompasses the rhythmic duration of a single note. And example would be a spanner that encompasses a single whole note and that says "pont. -----," (probably with downward-pointing right hook, as is conventional with ottava brackets); the meaning would be "play the entire duration of this note ponticello [and don't vary the color treatment at all]".

This comes up semi-regularly on the list; newcomers ask the question relatively frequently. The conventional answer is that you define a text spanner that connects two notes to each other (and style any right hook as markup on the second note). But surely this is a mis-model [and again I don't mean to critique harshly, rather helpfully for future thought]. Why? Because the line-breaking behavior of such spanners can never be made to behave correctly when the spanner "ends" on the first note after a line break. (Apologies for glossing here without providing an actual example; will make an effort do so in a separate thread very soon.)

So having only verbally glossed the idea of a length-1 spanner here, is there a relatively-easy-to-articulate reason that the text spanner implementation never grew to accommodate the generalization of a spanner encompassing only a single note? I assume the reason is historical rather than conceptual; but I'm interested in any case.

[Oh, and an extremely interesting point of comparison is that length-1 *tuplet brackets* work perfectly: \times 2/3 { c'1 } with tupletFullLength = ##t will draw the most perfect length-1 bracket you can imagine! It's almost like a miracle: the tuplet bracket always, always ends at *exactly* the correct end-point-of-the-duration-of-a-note; it's amazing how reliable the behavior is, and it works 100% perfectly with line breaking, too. It really seems that *all* spanners, without exception, should implement precisely that same behavior. Though surely that would be a very big change.]


Trevor.



--

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user