Re: Distance of a grob from its reference point

[Aaron Hill]

On 2020-01-16 4:01 pm, Paolo Prete wrote:
> This gives a clearer overview, thanks, but I would not use it, even if 
> it
> produces the wanted result.

Sorry if I implied otherwise, but I thought I was clear that this code 
was not intended for practical use.  This is only test code to 
demonstrate the underlying mechanisms are actually working properly.  I 
wanted to address what I consider a flawed premise that things are 
broken.  Rather, what should be clear is that things are complicated.  
And I am uncomfortable with so casually equating the two.


> I did not omit them, given that I did not want to reset any property, 
> as I
> explained in other posts. In practice, you are only making reset of all 
> the
> properties that add more space between the grob and the reference 
> point. At
> the end, considering that you have to add a .46 value, you get even a 
> worse
> procedure than \override Y-offset, while using the same logic (which 
> is:
> distance from a reference point, and not *offset the result*). So: I 
> think
> it's better to use a ruler from the middle of the staff.
> No other way, if you want to preserve the avoid-collision algo.

There is no "offset the result" apart from extra-offset.  There are many 
ways to *influence* the positioning of a grob, but only extra-offset 
operates on the final computed position.  Everything else works within 
the magic that is LilyPond's layout logic, which seems to be designed 
around keeping as much in relative terms as opposed to absolute terms.

With that in mind, say you want to move an object upward on the page.  
That is fine, but it is an absolute adjustment.  To convert it to a 
relative one, you must answer why you need to move the object.  Is it 
because it is too close to something?  Is it because it does not line up 
nicely with something else?  Is it because the decomposing remains of a 
donut you forgot about have become sentient and are whispering dark 
thoughts?

Once you have clarified why something needs to move, then you can best 
determine which tool is the right one for the job.  The goal is to move 
the object once, and not have to revisit it after other things change.  
Encoding the logic behind why something needs to move lets LilyPond do 
it for you.  Padding can help with adjusting how near or far objects are 
from one another, but sometimes alignment suffers.  Alignment of grobs 
requires working from a common reference point, and one will need to 
consider what constructs exist within LilyPond that can help with this.  
The Dynamics context, for instance, does not have to be used only for 
dynamics.  Of course, sometimes relative adjustments are just not 
suitable and you may end up needing to use the absolute extra-offset.  
As for the donut, that is beyond my pay grade, and I wish you only the 
best of luck.

(Future headline: Krispy Kreme responsible for zombie outbreak with 
Halloween-inspired glazed, "raised-from-the-dead" donuts.)

Of course, the tools and constructs available in LilyPond are certainly 
not exhaustive.  Given the discussion, it seems we could benefit greatly 
with the introduction of a so-called "outside-staff-offset" which moves 
grobs away from the staff by an absolute amount--think extra padding but 
only on the side nearest the staff.

If that sounds interesting, know that you can approximate it with a 
combination of outside-staff-padding and extra-offset to achieve 
outside-staff-offset.  It just takes a little grade-school math:

%%%%
\version "2.19.83"
notes = \fixed c''' { \mark "mark" \ottava 1 f8( 8) 4 \ottava 0 f,2 }

{
  \omit Staff.Clef \omit Staff.TimeSignature
  \override Score.RehearsalMark.self-alignment-X = #LEFT

  % Default behavior.
  \notes

  % Try moving the bracket up by two staff spaces.
  \override Staff.OttavaBracket.outside-staff-padding = 2.46
  \notes

  % Oops, the mark moved too far.
  % Split the difference between padding and offset.
  \override Staff.OttavaBracket.outside-staff-padding = 1.46
  \override Staff.OttavaBracket.extra-offset = #'(0 . 1)
  \notes
}
%%%%

But what happens when outside-staff-padding is *not* the defining 
property controlling the vertical position?  Consider a bracket whose 
effective Y-offset is large enough that it is positioned too far away 
from other outside-staff grobs.

This could be handled as followed:

%%%%
\version "2.19.83"

#(define (addRuler color left right)
  (grob-transformer 'stencil (lambda (grob orig)
    (ly:stencil-add
      (grob-interpret-markup grob #{
        \markup \with-dimensions-from \null
        \with-color #color \path #0.1 #`(
          (moveto ,left 0) (lineto ,right 0)
          (moveto ,left 1) (lineto ,right 1)
          (moveto ,left 2) (lineto ,right 2)
        ) #})
      orig))))

notesI = \fixed c''' { \mark "mark" \ottava 1 d8 8 4 \ottava 0 d,2 }
notesII = \fixed c''' { \mark "mark" \ottava 1 a8( 8) 4 \ottava 0 a,2 }

shiftOttavaBracket = #(define-music-function (amount) (number?)
  (let ((half (/ amount 2)))
    #{
      \offset Y-offset #half Staff.OttavaBracket
      \override Staff.OttavaBracket.outside-staff-padding = #(+ 0.46 
half)
      \override Staff.OttavaBracket.extra-offset = #`(0 . ,half)
    #}))

unshiftOttavaBracket = {
  \revert Staff.OttavaBracket.Y-offset
  \revert Staff.OttavaBracket.outside-staff-padding
  \revert Staff.OttavaBracket.extra-offset
}

{
  \omit Staff.Clef \omit Staff.TimeSignature
  \override Score.RehearsalMark.self-alignment-X = #LEFT

  % Test with bracket that is positioned by Y-offset.
  \override Staff.OttavaBracket.stencil = #(addRuler red -5 10)
  \notesI
  \shiftOttavaBracket 1
  \notesI
  \shiftOttavaBracket 2
  \notesI
  \unshiftOttavaBracket

  % Test with bracket that is positioned by outside-staff.
  \override Staff.OttavaBracket.stencil = #(addRuler blue -5 10)
  \notesII
  \shiftOttavaBracket 1
  \notesII
  \shiftOttavaBracket 2
  \notesII
}
%%%%

And lo and behold: \offset Y-offset is not setting the world ablaze.  (:

To be clear, again, this code is nothing more than a proof of concept.  
It would need to be adapted for practical use; but I truly hope folks 
can see that the tools for positioning really are there.  They just 
might not be as specialized as we would like.  I would still vote for a 
*real* outside-staff-offset, as the semantics are more obvious than 
trying to use a combination of other properties.

Whew, that was a lot of work for one email.  I could go for a donut.


-- Aaron Hill

offset.cropped.png
Description: PNG image