[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A metacomment on Re: Text spanner shorten-pair
From: |
David Wright |
Subject: |
A metacomment on Re: Text spanner shorten-pair |
Date: |
Wed, 13 Feb 2019 09:18:57 -0600 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
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 <address@hidden>
> Date: Wednesday, February 13, 2019 at 6:43 AM
> To: Carl Sorensen <address@hidden>
> Cc: Andrew Bernard <address@hidden>, lilypond-user Mailinglist
> <address@hidden>
> Subject: Re: Text spanner shorten-pair
>
>
>
> On Tue, Feb 12, 2019 at 6:12 PM Carl Sorensen
> <address@hidden<mailto:address@hidden>> wrote:
>
>
> From: Trevor Bača <address@hidden<mailto:address@hidden>>
> Date: Tuesday, February 12, 2019 at 3:09 PM
> To: Carl Sorensen <address@hidden<mailto:address@hidden>>
> Cc: Andrew Bernard <address@hidden<mailto:address@hidden>>, lilypond-user
> Mailinglist <address@hidden<mailto:address@hidden>>
> Subject: Re: Text spanner shorten-pair
>
> On Fri, Jan 25, 2019 at 11:38 AM Carl Sorensen
> <address@hidden<mailto: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.
>
> 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.