Re: "Padding" at system start

[David Nalesnik]

Hi Urs,

On Fri, Mar 24, 2017 at 4:56 AM, Urs Liska <address@hidden> wrote:
> Hi all,
>
> in the threads
> http://lists.gnu.org/archive/html/lilypond-user/2017-03/msg00234.html
> and espcially
> http://lists.gnu.org/archive/html/lilypond-user/2017-03/msg00356.html
>
> I struggled with the behaviour of shifting a note column at system start
> using its X-offset property. Obviously there's some threshold before it
> takes any visible effect. Using an elaborate testing file drawing rulers
> and boxes at different positions I now got to the bottom of the problem
> - nearly. I'll write this down ASAP when I've fully understood the issue.
>
> My challenge is to produce space at the beginning of a system to draw an
> element of a fixed width. You can see that from the red box in the
> attached PNG (which reflects the final solution). My initial idea to
> calculate the missing space (from the distance between the clef and the
> accidentals) and set NoteColumn.X-offset to that value didn't work (as
> described in the earlier threads).
>
> The attached PDF shows what happens when the X-offset is increased step
> by step. The border of the system-start NonMusicalPaperColumn is
> indicated with a blue line reflect the accidentals' origin and X-extent.
>
> Obviously the reference point of the accidentals is the X position of
> the note column minus the note column's X-offset, which you can see from
> the fact that the distance of the pink vertical line always relfects the
> X-offset value.
>
> However, up to a certain point (in the example this is an X-offset of
> 4.875) the whole thing is shifted to the right and continuously
> approaches the state when the pink line coincides with the box around
> the accidentals (or when the accidentals' (car X-extent) has reached
> zero. Up to that point increasing the X-offset of the note column
> doesn't have a visible effect but only moves around the origin and the
> accidentals' X-extent. But *after* that point increasing X-offset beyond
> 4.875 pushes the chord to the right as one would expect. It seems that
> the pink reference point (recall: the note column's X position minus its
> X-offset) remains stable, and it obviously is the point where by default
> notes would start, as you can see from the last example in the PDF.
>
> My conclusion of this is that LilyPond enforces a padding between the
> clef (or time or key signature, which behave identially if present) and
> the first note column. However, if there are accidentals attached to the
> note column they are allowed to protrude into that padding area.
>
> ###
>
> So, now finally comes my question: I have determined this padding to be
> exactly 2 staff spaces wide, but I'm wondering if that is hard-coded in
> LilyPond or ruled by a property. Actually I'd be surprised if it's not
> possible to modify this aspect of appearance, but I have to know if I
> can simply insert the "2" into my calculations or if I have to retrieve
> that value from a property to make the calculation robust.
>
> I poked around in the reference for NonMusicalPaperColumn but didn't
> find anything that looked promising. I can override its #'padding, but
> that doesn't seem to have any effect at the system start (only within a
> system).
> It would seem that line-break-system-details would be a starting point,
> but
> http://lilypond.org/doc/v2.19/Documentation/notation/explicit-staff-and-system-positioning
> doesn't give anything for my question, and the IR for
> NonMusicalPaperColumn and paper-column-interface seem to be happy with
> "An alist of properties to use if this column is the start of a system."
>
> Any clarification or pointers available?

I would have a look at LeftEdge.space-alist.  The 2.0 looks
suspiciously like first-note.fixed-space.

HTH,
David