Re: stacking of figured bass elements
Le 12/06/2022 à 17:36, Werner LEMBERG a écrit :
Consider the following example:
```
\figures {
}
```
As can be seen in the attached image, the elements are separated by
padding only; they are not vertically spaced using `baseline-skip` or
something similar.
How can I change that?
Like this?
\version "2.23.9"
\figures {
\override BassFigureAlignment.padding = 5
}
Jean
Re: stacking of figured bass elements
>> Consider the following example:
>>
>> ```
>> \figures {
>>
>> }
>> ```
>>
>> As can be seen in the attached image, the elements are separated by
>> padding only; they are not vertically spaced using `baseline-skip`
>> or something similar.
>>
>> How can I change that?
>
> Like this?
>
> \version "2.23.9"
>
> \figures {
> \override BassFigureAlignment.padding = 5
>
> }
Nope, this only changes the padding (i.e., the whitespace between the
bottom of the upper and the top of the lower element). What I want is
vertical stacking as if it were done with the `\column` markup command
– which respects `baseline-skip`.
Werner
Re: stacking of figured bass elements
Le 12/06/2022 à 17:55, Werner LEMBERG a écrit : Nope, this only changes the padding (i.e., the whitespace between the bottom of the upper and the top of the lower element). What I want is vertical stacking as if it were done with the `\column` markup command – which respects `baseline-skip`. Then I don't understand the problem. What characteristic of baseline-skip do you wish? Is it that it counts from the origin of each markup and somehow this distance is more convenient for you to provide? Is it that it ignores the extents of the markups? Could you explain the overarching problem? To me, this sounds like an XY question. Best, Jean
Re: stacking of figured bass elements
Hi Jean,
> Then I don't understand the problem. What characteristic
> of baseline-skip do you wish? Is it that it counts from
> the origin of each markup and somehow this distance is
> more convenient for you to provide? Is it that it ignores
> the extents of the markups?
>
> Could you explain the overarching problem? To me, this
> sounds like an XY question.
This sounds like it might be related to my [long-standing] concerns about
leading, etc., in markups: there either isn’t a convenient mechanism to deal
with texts/markups *from their baseline [and not their reference point]*, or
the convenient mechanism exists and isn’t sufficiently well
exposed/documented/promoted.
{
\override TextScript.padding = #2
g'1^\markup { agt }
g'1^\markup { aht }
}
Cheers,
Kieren.
Re: stacking of figured bass elements
> Then I don't understand the problem. What characteristic of
> baseline-skip do you wish? Is it that it counts from the origin of
> each markup and somehow this distance is more convenient for you to
> provide? Is it that it ignores the extents of the markups?
I want equal vertical spacing of lines. Here is a small snippet that
compares `\column` with `\figures`. I want the spacing of the former
to be available for the latter.
```
\figures {
\override BassFigureAlignment.padding = 1
}
\markup {
\override #'(baseline-skip . 2) {
\column { b a g }
\column { b b g }
}
}
```
Werner
Re: stacking of figured bass elements
> This sounds like it might be related to my [long-standing] concerns > about leading, etc., in markups: there either isn’t a convenient > mechanism to deal with texts/markups *from their baseline [and not > their reference point]*, or the convenient mechanism exists and > isn’t sufficiently well exposed/documented/promoted. It looks superficially similar, but I think it is a completely different mechanism behind the scenes. AFAICS, the vertical spacing of vertically stacked figured bass elements uses a special routine `ly:align-interface::align-to-minimum-distances` in grob `BassFigureAlignment`. In the source code (function `Align_interface::internal_get_minimum_translations` in file `align-interface.cc`) I see that the function also listens to `basic-distance` (probably from `VerticalAxisGroup`), but I wasn't able to trigger it – most probably, this code part is not specific to figured bass. Werner
Re: stacking of figured bass elements
Le 12/06/2022 à 19:11, Werner LEMBERG a écrit :
This sounds like it might be related to my [long-standing] concerns
about leading, etc., in markups: there either isn’t a convenient
mechanism to deal with texts/markups *from their baseline [and not
their reference point]*, or the convenient mechanism exists and
isn’t sufficiently well exposed/documented/promoted.
It looks superficially similar, but I think it is a completely
different mechanism behind the scenes. AFAICS, the vertical spacing
of vertically stacked figured bass elements uses a special routine
`ly:align-interface::align-to-minimum-distances` in grob
`BassFigureAlignment`. In the source code (function
`Align_interface::internal_get_minimum_translations` in file
`align-interface.cc`) I see that the function also listens to
`basic-distance` (probably from `VerticalAxisGroup`), but I wasn't
able to trigger it – most probably, this code part is not specific to
figured bass.
I think this should do (I can elaborate when I have more time):
\version "2.22.2"
\figures {
\override BassFigureLine.staff-staff-spacing = #'((basic-distance . 0)
(minimum-distance . 1.6)
(padding . -inf.0)
(stretchability . 0))
< f I \markup r >
}
Cheers,
Jean
Re: stacking of figured bass elements
Kieren MacMillan writes:
> Hi Jean,
>
>> Then I don't understand the problem. What characteristic
>> of baseline-skip do you wish? Is it that it counts from
>> the origin of each markup and somehow this distance is
>> more convenient for you to provide? Is it that it ignores
>> the extents of the markups?
>>
>> Could you explain the overarching problem? To me, this
>> sounds like an XY question.
>
> This sounds like it might be related to my [long-standing] concerns
> about leading, etc., in markups: there either isn’t a convenient
> mechanism to deal with texts/markups *from their baseline [and not
> their reference point]*, or the convenient mechanism exists and isn’t
> sufficiently well exposed/documented/promoted.
>
> {
> \override TextScript.padding = #2
> g'1^\markup { agt }
> g'1^\markup { aht }
> }
I have problems believing we did not have this particular discussion
already since there is a documented setting for it.
{
\override TextScript.staff-padding = #1.5
g'1^\markup { agt }
g'1^\markup { aht }
}
--
David Kastrup
Re: stacking of figured bass elements
Hi David,
> I have problems believing we did not have this particular discussion
> already since there is a documented setting for it.
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
}
Cheers,
Kieren.
Re: stacking of figured bass elements
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. Consequently, it does not align consecutive
scripts as if they were set as a line of text. To wit:
{
\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)
but I don't think this matters for the present discussion.
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 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.
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
}
Best,
Jean
Re: stacking of figured bass elements
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. Consequently, it does not align consecutive
scripts as if they were set as a line of text. To wit:
{
\override TextScript.padding = ##f % now only staff-padding counts
c'1^"afg" c'^"aht" c'^"afg"
}
You gave a convincing example and I just ignored it. Sorry for looking
at this too fast. I'll come back to it with more time.
Re: stacking of figured bass elements
Hi all,
Sorry for the typo in the last email… Here’s a “correct incantation”:
\version "2.23.4"
{
\override Score.RehearsalMark.padding = #2
\mark \markup { agt } g'1
\mark \markup { aht } g'1
\mark \markup { agt } g'1
}
I put “correct incantation” in quotes because it moves the RehearsalMarks, but
it’s not staff-padding [which would be consistent with the TextScript setting
David used], and it doesn’t align the markups to their baseline [as most users
would reasonably expect, and which would be consistent with other settings
like, apparently, TextScript.staff-padding].
This hodge-podge of apparently inconsistent parameters and behaviours is what I
refer to when I talk about how the markup handling in Lilypond isn’t optimal.
Cheers,
Kieren.
Re: stacking of figured bass elements
p.s. To be clear, \override-ing Score.RehearsalMark.staff-padding does nothing,
which is a related but separate point of inconsistency.
— Kieren
> On Jun 12, 2022, at 3:37 PM, Kieren MacMillan
> wrote:
>
> Hi all,
>
> Sorry for the typo in the last email… Here’s a “correct incantation”:
>
> \version "2.23.4"
> {
> \override Score.RehearsalMark.padding = #2
> \mark \markup { agt } g'1
> \mark \markup { aht } g'1
> \mark \markup { agt } g'1
> }
>
> I put “correct incantation” in quotes because it moves the RehearsalMarks,
> but it’s not staff-padding [which would be consistent with the TextScript
> setting David used], and it doesn’t align the markups to their baseline [as
> most users would reasonably expect, and which would be consistent with other
> settings like, apparently, TextScript.staff-padding].
>
> This hodge-podge of apparently inconsistent parameters and behaviours is what
> I refer to when I talk about how the markup handling in Lilypond isn’t
> optimal.
>
> Cheers,
> Kieren.
Re: stacking of figured bass elements
Hi Jean, > I don't understand how staff-padding relates to this discussion. It relates to the discussion as follows: — when one wants to align TextScripts above the staff to their baseline(s), one apparently uses staff-padding; — when one wants to align RehearsalMarks (or, probably, MetronomeMarks) above the staff to their baseline(s), staff-padding apparently doesn't apply. Even as a veteran, I find aligning text above the staff a frustratingly multi-attempt process — I can only imagine what a beginning user goes through. Cheers, Kieren.
Re: stacking of figured bass elements
Hi Jean,
Sorry I didn’t respond to this:
> 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
> }
Well, yes… and I’ve used that mechanism in my scores. My frustration is that
we’re already talking about three different parameters — padding,
staff-padding, and Y-offset — which are used in order to align text above
staves to their baseline (which is what the hypothetical user is trying to do),
and they behave differently (inconsistently, not at all, etc.) across different
grobs.
Am I the only one who sees this situation as sub-optimal?
Thanks,
Kieren.
Re: stacking of figured bass elements
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 on
Re: stacking of figured bass elements
Hi Jean, Thanks for this really in-depth explanation! Despite having used Lilypond for twenty years, and RTFineM[s] multiple times, in great depth, your analysis/presentation contained new information/insights for me. > If a letter protrudes on the bottom like "g" > (not sure how this would be called in font terms?) “descender” > Now let me try to summarize the situation. [snip] > Go explain the above to the average user. um… yeah. — K
Re: stacking of figured bass elements
Jean Abou Samra writes: [...] > 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. In my experience, when a situation is incoherent due to technical reasons to a degree where I consider it sort of hopeless "to explain it to the average user", namely document it in a manner that is more cohesive than tracing all code paths, there is some merit in changing it. Ideally, we'd want to get to the point where we can without fear ask the question "how would you rather have it?" and never need to draw the "you wouldn't understand the reason" card in the course of the ensuing discussion. There's been some corners of LilyPond where I've been able to make progress in that respect. The backend certainly is not one of them. -- David Kastrup
Re: stacking of figured bass elements
>> I see that the function also listens to `basic-distance` (probably
>> from `VerticalAxisGroup`), but I wasn't able to trigger it – most
>> probably, this code part is not specific to figured bass.
>
> I think this should do (I can elaborate when I have more time):
>
> \version "2.22.2"
>
> \figures {
> \override BassFigureLine.staff-staff-spacing =
> #'((basic-distance . 0)
> (minimum-distance . 1.6)
> (padding . -inf.0)
> (stretchability . 0))
> < f I \markup r >
> }
Aah, not `VerticalAxisGroup` but `BassFigureLine` it is! Excellent,
thanks!
One question remains, however: Why `staff-staff-spacing` and not
`nonstaff-nonstaff-spacing`? Or to ask the question differently: How
can I recognize the difference between 'staff' and 'nonstaff' material
in general?
Werner
Re: stacking of figured bass elements
Le 13/06/2022 à 07:31, Werner LEMBERG a écrit :
I see that the function also listens to `basic-distance` (probably
from `VerticalAxisGroup`), but I wasn't able to trigger it – most
probably, this code part is not specific to figured bass.
I think this should do (I can elaborate when I have more time):
\version "2.22.2"
\figures {
\override BassFigureLine.staff-staff-spacing =
#'((basic-distance . 0)
(minimum-distance . 1.6)
(padding . -inf.0)
(stretchability . 0))
< f I \markup r >
}
Aah, not `VerticalAxisGroup` but `BassFigureLine` it is! Excellent,
thanks!
One question remains, however: Why `staff-staff-spacing` and not
`nonstaff-nonstaff-spacing`? Or to ask the question differently: How
can I recognize the difference between 'staff' and 'nonstaff' material
in general?
Everything with a staff-affinity is "nonstaff", all
the rest is "staff". (See Page_layout_problem::is_spaceable
in lily/page-layout-problem.cc.)
By the way, here is a better snippet:
\version "2.22.2"
\figures {
\override BassFigureLine.staff-staff-spacing =
#'((minimum-distance . 1.6)
(padding . -inf.0))
< f I \markup r >
}
Giving values for basic-distance and stretchability was
in fact pointless: since BassFigureAlignment uses
ly:align-interface::align-to-minimum-distances,
it only takes minimum-distance and padding into account.
Best,
Jean
