Re: "Padding" at system start

[Urs Liska]

Hi David,

Am 24. März 2017 16:26:44 MEZ schrieb David Nalesnik <address@hidden>:
>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.
>

Thank you, this looks very promising, and I'll look into it when I'm home again.

Urs


>HTH,
>David