Re: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset "upside down"?

[Carl Sorensen]

On 1/1/22, 2:43 PM, "Jean Abou Samra"  wrote:


I don't know much about the code that places systems on
the page, but I think the issue is just that there are
two code paths applying extra-offsets, with two different
coordinate systems.

You are certainly correct.  Thank you for clarifying it.

Carl

Re: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset "upside down"?

[Jean Abou Samra]

Le 01/01/2022 à 22:21, Carl Sorensen a écrit :


On 1/1/22, 2:05 PM, "Kieren MacMillan"  wrote:

 Hi Carl,
 
 > I assume it is because the negative offset reduces the skyline of the broken (following) system, which allows the spacing engine to raise that system.
 
 But extra-offset doesn't (or at least shouldn't) affect the spacing engine, right?


extra-offset affects the position of grobs *relative to the staff containing 
them*.  When the Y position of a grob is increased, it either has no affect on 
the location of the staff, or it lowers the staff due to required spacing from 
the staff above.  Since after-line-breaking is the bottom staff, a positive Y 
extra-offset value should have no affect or lower the bottom staff, to be 
consistent with positive Y extra-offset for every other grob on the staff, it 
seems to me.

extra-offset doesn’t change the staff-staff spacing parameters, but it does 
change the grob locations used in the staff-staff spacing calculations.

I think this is all consistent, but I could be wrong.



I am pretty sure that page spacing calculations are
insensitive to extra offsets. For example:

\version "2.22.1"

<<
  \new Staff {
    \once \override Staff.Clef.Y-offset = -20
    c'1
  }
  \new Staff { c'1 }
>>

<<
  \new Staff {
    \once \override Staff.Clef.extra-offset = #'(0 . -20)
    c'1
  }
  \new Staff { c'1 }
>>


extra-offset of all grobs but a System itself is handled
in system.cc:

SCM
System::get_paper_system ()
{
  [...]
  for (vsize j = 0; j < entries.size (); j++)
    {
  Grob *g = entries[j].grob_;
  Stencil st = g->get_print_stencil ();

  if (scm_is_null (st.expr ()))
    continue;

  Offset o;
  for (const auto a : {X_AXIS, Y_AXIS})
    o[a] = g->relative_coordinate (this, a);

  Offset extra = from_scm (get_property (g, "extra-offset"),
   Offset (0, 0))
 * Staff_symbol_referencer::staff_space (g);

  /* Must copy the stencil, for we cannot change the stencil
 cached in G.  */

  st.translate (o + extra);

  *tail = scm_cons (st.expr (), SCM_EOL);
  tail = SCM_CDRLOC (*tail);
    }

  if (auto *me = get_stencil ())
    exprs = scm_cons (me->expr (), exprs);

  Interval x (extent (this, X_AXIS));
  Interval y (extent (this, Y_AXIS));
  Stencil sys_stencil (Box (x, y),
   scm_cons (ly_symbol2scm ("combine-stencil"),
 exprs));
  [...]

  Paper_column *left_bound = get_bound (LEFT);
  SCM prop_init = get_property (left_bound, "line-break-system-details");
  Prob *pl = make_paper_system (prop_init);
  paper_system_set_stencil (pl, sys_stencil);

  /* information that the page breaker might need */
  Paper_column *right_bound = get_bound (RIGHT);
  set_property (pl, "vertical-skylines", get_property (this, 
"vertical-skylines"));
  set_property (pl, "page-break-permission", get_property (right_bound, 
"page-break-permission"));
  set_property (pl, "page-turn-permission", get_property (right_bound, 
"page-turn-permission"));
  set_property (pl, "page-break-penalty", get_property (right_bound, 
"page-break-penalty"));
  set_property (pl, "page-turn-penalty", get_property (right_bound, 
"page-turn-penalty"));


  [...]
}


So this takes extra-offset into account when constructing
the big stencil that gathers all stencils of a system's
grobs, but that big stencil's extent is taken from
the System's X-extent and Y-extent, which do not take
extra offsets into account, and same for the skyline.
The whole system is therefore insensitive to extra offsets
with regard to spacing (and so are the VerticalAxisGroups
for spacing between staves).

I don't know much about the code that places systems on
the page, but I think the issue is just that there are
two code paths applying extra-offsets, with two different
coordinate systems.

Kind regards,
Jean

Re: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset "upside down"?

[Kieren MacMillan]

Hi Jean,

> Within a system, positive Y offsets move higher because
> that is how we humans tend to think. However, page spacing
> all works with Y offsets going down.

Ah… That makes sense. Or at least the logic is internally consistent.  ;)
Thanks for clarifying it for me.

A note for any future thread readers: the docs at 

 describe the current behaviour accurately.

I am satisfied that the current behaviour is likely optimal — I just need to 
get it through my head.  =)

Cheers,
Kieren.

Re: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset "upside down"?

[Kieren MacMillan]

Hi Carl,

> extra-offset affects the position of grobs *relative to the staff containing 
> them*.  When the Y position of a grob is increased, it either has no affect 
> on the location of the staff, or it lowers the staff due to required spacing 
> from the staff above.  Since after-line-breaking is the bottom staff, a 
> positive Y extra-offset value should have no affect or lower the bottom 
> staff, to be consistent with positive Y extra-offset for every other grob on 
> the staff, it seems to me.
> 
> extra-offset doesn’t change the staff-staff spacing parameters, but it does 
> change the grob locations used in the staff-staff spacing calculations.
> 
> I think this is all consistent, but I could be wrong.

 says:

"extra-offset
This property applies to any layout object supporting the grob-interface. It 
takes a pair of numbers which specify the extra displacement in the horizontal 
and vertical directions. Negative numbers move the object to the left or down. 
The units are staff-spaces. The extra displacement is made after the 
typesetting of objects is finished, so an object may be repositioned anywhere 
without affecting anything else."

From that description, I (perhaps incorrectly?) expect two things:

1. Negative extra-offset [Y-values] in 
NonMusicalPaperColumn.line-break-system-details should move the system *down*.

2. Such a tweak [in any direction] shouldn't be considered at all in the 
staff-staff-spacing calculations.

IMO, either the documentation should be updated to reflect the reality, or the 
behavior of NonMusicalPaperColumn.line-break-system-details extra-offset should 
be modified to match the documentation [and the effect of extra-offset in every 
other situation].

Cheers,
Kieren.

Re: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset "upside down"?

[Jean Abou Samra]

Le 01/01/2022 à 21:30, Kieren MacMillan a écrit :

Hi all,

(Happy New Year!)

Is there a logical reason that for most tweaks negative extra-offset values 
move the associated grob vertically lower on the page, but with 
NonMusicalPaperColumn.line-break-system-details it moves the associated system 
*higher* on the page?

I offer it would be better if extra-offset had a consistent behaviour/effect.



Within a system, positive Y offsets move higher because
that is how we humans tend to think. However, page spacing
all works with Y offsets going down. That might be a little
more convenient a convention because systems are placed with
increasing Y offsets. It's easy to fix the direction of the
Y part of paper systems' extra-offsets ...

diff --git a/scm/page.scm b/scm/page.scm
index 01c167c6e2..d4807ab189 100644
--- a/scm/page.scm
+++ b/scm/page.scm
@@ -249,7 +249,7 @@ of layout settings just like markups inside the music"
  (extra-offset (ly:prob-property system 'extra-offset 
'(0 . 0)))

  (x (+ (ly:prob-property system 'X-offset 0.0)
    (car extra-offset)))
- (y (+ (ly:prob-property system 'Y-offset 0.0)
+ (y (- (ly:prob-property system 'Y-offset 0.0)
    (cdr extra-offset)))
  (is-title (paper-system-title?
 system)))


... but it is trickier to design a convert-ly rule to
fix existing user files.

Regards,
Jean

Re: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset "upside down"?

[Carl Sorensen]

On 1/1/22, 2:05 PM, "Kieren MacMillan"  wrote:

Hi Carl,

> I assume it is because the negative offset reduces the skyline of the 
broken (following) system, which allows the spacing engine to raise that system.

But extra-offset doesn't (or at least shouldn't) affect the spacing engine, 
right?

extra-offset affects the position of grobs *relative to the staff containing 
them*.  When the Y position of a grob is increased, it either has no affect on 
the location of the staff, or it lowers the staff due to required spacing from 
the staff above.  Since after-line-breaking is the bottom staff, a positive Y 
extra-offset value should have no affect or lower the bottom staff, to be 
consistent with positive Y extra-offset for every other grob on the staff, it 
seems to me.

extra-offset doesn’t change the staff-staff spacing parameters, but it does 
change the grob locations used in the staff-staff spacing calculations.

I think this is all consistent, but I could be wrong.

Carl

Re: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset "upside down"?

[Kieren MacMillan]

Hi Carl,

> I assume it is because the negative offset reduces the skyline of the broken 
> (following) system, which allows the spacing engine to raise that system.

But extra-offset doesn't (or at least shouldn't) affect the spacing engine, 
right?

Kieren

Re: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset "upside down"?

[Carl Sorensen]

I assume it is because the negative offset reduces the skyline of the broken 
(following) system, which allows the spacing engine to raise that system.

Carl

Sent via the Samsung Galaxy S®6 active, an AT 4G LTE smartphone
Get Outlook for Android

From: lilypond-devel 
 on behalf of 
Kieren MacMillan 
Sent: Saturday, January 1, 2022 1:30:20 PM
To: LilyPond development 
Subject: Why is NonMusicalPaperColumn.line-break-system-details.extra-offset 
"upside down"?

Hi all,

(Happy New Year!)

Is there a logical reason that for most tweaks negative extra-offset values 
move the associated grob vertically lower on the page, but with 
NonMusicalPaperColumn.line-break-system-details it moves the associated system 
*higher* on the page?

I offer it would be better if extra-offset had a consistent behaviour/effect.

Thanks,
Kieren.