On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen <address@hidden> 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.