Le 21/03/2022 à 12:38, Robin Bannister a écrit :
Hallo there
In the Notation Reference for v2.12 through to (currently) v2.23, the
section 'Explicit staff and system positioning' says:
Note that line-break-system-details takes an associative list of
potentially many values, but that we set only one value here. Note,
too, that the Y-offset property here determines the exact vertical
position on the page at which each new system will render.
That bit about 'determines the exact vertical position' was written
during v2.11 and described v2.12 behaviour. But v2.13 started doing
it differently, and that discrepancy between docs and code still exists.
Allow me to disagree: "vertical position on the page at which each new
system will render" does not specify which refpoint in the system is
aligned to the given offset. I don't see that the documentation is
inaccurate. Also, having the top of the system as the refpoint is a
simple and logical rule. The patch from Joe makes the refpoint the top
of the first staff-like context. What if there are only Dynamics
contexts and such in the score? Whatever it does, the rule will not be
as straightforward to understand.
Changing this will be painful since it will be silent in existing scores
and convert-ly will not be able to fix input files automatically.
Plus, why the top staff and not the center of the interval between the
top one and the bottom one -- wouldn't that be more logical for
balancing the space between systems on the page? I am afraid there are
too many possible use cases for line-break-system-details to design a
sane rule making all of them easy. Better would be a way of aligning the
baseline of a specific context at a given vertical point.
Jean
I think the user thread
https://lists.gnu.org/archive/html/lilypond-user/2011-05/msg00332.html
can serve as a bug report for the current situation. It summarises the
situation and provides MWEs and even includes a patch.
That patch wasn't applied, perhaps because Trevor Bača's particular
problem was solved without resort to line-break-system-details.
I suppose it stayed that way because when moving a _single_ line you
use trial and error to arrive at a suitable value. Or when aligning
_two_ lines there are more familiar methods to fall back on, so any
temporary inaccuracy or confusion becomes irrelevant (cf mirrored.png).
In
https://lists.gnu.org/archive/html/lilypond-user/2022-03/msg00224.html
pseudoIndentsYdemo.ly's apply-Y-pos uses line-break-system-details
with a crude workaround. If you gradually reduce even-taller's value,
the end of scoreA starts moving at 7 and scoreE bit later. I ought to
be able to align the 3 fragments of line 4 in a clean LilyPond way.
Cheers,
Robin
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
