"Padding" at system start

[Urs Liska]

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?
Thanks
Urs

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org

beginning-of-staff.png
Description: PNG image

beginning-of-staff.pdf
Description: Adobe PDF document

beginning-of-staff.ly
Description: Text Data