Re: stacking of figured bass elements

[Jean Abou Samra]

OK, trying to correct myself and articulate a little more coherent
thoughts this time. Sorry, I was hearing about election results in
France at the same time and was distracted.


I wrote:

Le 12/06/2022 à 21:32, Jean Abou Samra a écrit :
> Le 12/06/2022 à 21:08, Kieren MacMillan a écrit :
> > Hi David,
> >
> > > I have problems believing we did not have this particular discussion
> > > already since there is a documented setting for it.
>
>
> I don't understand how staff-padding relates to this discussion.
> It counts from the reference point of the markup, which for text
> is usually the bottom.



Wrong, it is the baseline to which letters align. If a letter
protrudes on the bottom like "g" (not sure how this would be
called in font terms?), the reference point is not at the bottom
of the printed ink but near the bottom of the upper round part.



> Consequently, it does not align consecutive
> scripts as if they were set as a line of text. To wit:


Wrong, it does if you increase it, or if you set
outside-staff-padding to 0.


> {
>   \override TextScript.padding = ##f % now only staff-padding counts
>   c'1^"afg" c'^"aht" c'^"afg"
> }
>
>
>
> > The problem isn’t really whether there’s a documented setting or not… 
> > It’s whether that documented setting is consistently applied and 
> > behaves in the way most users would instinctively expect.
> >
> > \version "2.23.4"
> >
> > {
> >   \override MetronomeMark.staff-padding = #1.5
> >   \mark \markup { agt } g'1
> >   \mark \markup { aht } g'1
> >   \mark \markup { agt } g'1
> > }
>
>
> Did you mean "Score.RehearsalMark" instead of "MetronomeMark"?
>
> Apart from that, RehearsalMark doesn't listen to staff-padding,
> only to padding
> (https://gitlab.com/lilypond/lilypond/-/issues/342)


Correct.


> but I don't think this matters for the present discussion.


Wrong, staff-padding works with the reference points unlike padding,
which is relevant.


> > in markups: there either isn’t a convenient mechanism to deal with 
> > texts/markups *from their baseline [and not their reference point]*,
>
>
> As a side note, right now, side positioning is done via skylines,
> which is a bit different from just using the reference point.


That is not a side note but the whole point of the discussion.


> That doesn't change the fact that markups made of letters with
> varying heights have their bottoms aligned when there aren't
> any objects nearby that they need to avoid, which leads to the
> problem at hand.


It depends on the respective values of padding, staff-padding,
outside-staff-padding and more.


> > or the convenient mechanism exists and isn’t sufficiently well 
> > exposed/documented/promoted.
>
>
> For a start, this can be useful:
>
> {
>   \override Score.RehearsalMark.Y-offset = 4
>   \mark \markup { agt } g'1
>   \mark \markup { aht } g'1
>   \mark \markup { agt } g'1
> }


Correct.


Now let me try to summarize the situation. There are three measures
by which objects can be aligned vertically:

1. By ensuring a minimum distance from their reference point to something.
2. By ensuring a minimum distance from the bottom of their Y-extent
   to something.
3. By taking their bottom vertical skyline and ensuring a minimum distance
   from this skyline to a skyline made with the elements that the grob
   is trying to avoid.

Only measure (1) leads to equal alignment of texts that only differ
by letters going down like "j".

The basis for determining a placement is Y-offset. This is just the
offset from the parent's reference point to this grob's reference point,
i.e. it works as (1). However, as soon as outside-staff-priority is set,
it does a second pass of spacing, which makes the eventual vertical offset
different from what the user may have set with Y-offset.

The Y-offset provided by the side-position-interface takes these
main parameters into account:

- padding. This is measured with skylines, i.e. (3).

- staff-padding. To my great surprise, this appears to be measured with
  the grob's refpoint, i.e. (1). The reason I am surprised is that other
  thingg called 'padding' (padding, staff-staff-spacing.padding, 
outside-staff-padding,
  horizon-padding, outside-staff-horizon-padding) are all about skylines.
  I would say that either the naming or the behavior is inconsistent in
  that regard.

  A known quirk is that staff-padding does not work for Score-level
  grobs like RehearsalMark, issue 
https://gitlab.com/lilypond/lilypond/-/issues/342

- minimum-space. This is just a minimum distance from the parent's
  refpoint to the grob's refpoint, i.e. it works via method (1).

In addition, if the object has an outside-staff-priority, there
is the parameter:

- outside-staff-padding, which works with method (3), i.e. skylines.
  As soon as there are outside-staff collisions, there are fixed using
  this padding.

If you want to get natural alignment of text, you need to use a setting
that works with method (1).

Setting Y-offset works for this purpose. However, it makes the
grob no longer respond to collisions without outside-staff-priority.
With outside-staff-priority, the only collisions considered are
those with objects having an outside-staff-priority themselves,
which may not include all objects from the support. Furthermore,
it changes the padding setting that applies (outside-staff-padding
instead of padding).

staff-padding also works for this purpose. However, it may be trumped by
other settings if they lead to larger offset values. You likely need
to reduce padding and outside-staff-padding. This changes the spacing
in situations where there are collisions. Independently, staff-padding
does not work for Score objects.

minimum-space also works, but suffers from issues similar to staff-padding.

On top of all this, there are even more parameters influencing
collision avoidance, like slur-padding, horizon-padding and
outside-staff-horizon-padding.

Go explain the above to the average user.


> Am I the only one who sees this situation as sub-optimal?

No.


Best,
Jean