Hi Urs, On Fri, Mar 24, 2017 at 4:56 AM, Urs Liska <u...@openlilylib.org> 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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user