On Wed, Feb 13, 2019 at 8:33 AM Carl Sorensen <[email protected]> wrote:
> > > > > *From: *Trevor Bača <[email protected]> > *Date: *Wednesday, February 13, 2019 at 6:43 AM > *To: *Carl Sorensen <[email protected]> > *Cc: *Andrew Bernard <[email protected]>, lilypond-user > Mailinglist <[email protected]> > *Subject: *Re: Text spanner shorten-pair > > > > > > > > On Tue, Feb 12, 2019 at 6:12 PM Carl Sorensen <[email protected]> wrote: > > > > > > *From: *Trevor Bača <[email protected]> > *Date: *Tuesday, February 12, 2019 at 3:09 PM > *To: *Carl Sorensen <[email protected]> > *Cc: *Andrew Bernard <[email protected]>, lilypond-user > Mailinglist <[email protected]> > *Subject: *Re: Text spanner shorten-pair > > > > On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen <[email protected]> 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. -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca
_______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
