Le 05/04/2021 à 12:00, Thomas Morley a écrit :
Hi Jean,
thanks for your reply, though the situation is more complex than the
initial minimal. Consider the following:
{ b'4\glissando 4 4 4 2 b'' }
The plan is to print a glissando from b' to b'' and at intermediate
NoteColumns print a Stem starting at the glissando line, i.e. the
result will be a stemmed Glissando.
(1) Obviously I need the intersection points of the y-axis of the
Stems and the Glissando.
I've coded an engraver to set the relevant pointers (from Stem to
Glissando) and use some calculations to get them. This work is done.
(2) Then I intend to move all NoteHeads of intermediate NoteColumns to
sit on the glissando line, making them transparent (or point-stencil
or omit the stencil)
This would have the advantage that LilyPond could do the rest, i.e.
print Stem, Beam, Script etc accordingly.
Obviously the calculation of the intersection points needs to be done
after the Glissando is printed, thus a simple override for
NoteHead.Y-offset will not work, afaict.
From description in the docs about unpure-pure-containers, this is a
similar situation as for Beams and needed Stem lengths.
Alas, I never came to grips with unpure-pure-containers. Granted, the
explanations/descriptions in the docs improved over the years.
Though, we don't have working coding-examples in the docs, "working"
in the sense of "let me play with the code, testing what happens if I
do this and that":
The example in NR 5.5.6 works with and without unpure-pure-containers.
The example (sort of) in CG 10.13.3 makes no sense to me, at least I
found no situation where "bar" is called at all.
The regtest unpure-pure-container.ly is probably ok as a regtest, it
shows something is done, but why should a user do that at all. As a
user I'd say, don't move the flag if you don't want a moved flag...
That's it for the docs or did I overlook something?
Unpure-pure-containers in LSR: zero
Valentin's example works without unpure-pure-container as well.
Thus, I'm at a loss, close to abandoning the work.
Nevertheless, many thanks,
Harm
P.S. attached an image what works so far (but don't enable skylines)
Harm,
Could you send the code you have so far? I'd like to give
fixing the skylines a try.
I totally agree that unpure-pure containers are a headache
to understand. The docs could certainly use an update
(I'll have some news to share about that shortly). The
problem is, it's pretty difficult to find a compelling
example for pure functions. With, say, engravers, you
can write: here's a nice engraver that highlights part
of the music, or draws lines between any two notes, etc.
With pure functions, all you have is: this pure-unpure
container is the only way to avoid a cyclic dependency;
or: with this pure function, the spacing is slightly
snugger, observe how the second system is 1 cm higher.
It's not as exciting...
The only example I can think of is
\version "2.23.2"
% #(ly:set-option 'debug-skylines)
\new Voice \with {
\override TextScript.Y-extent = #ly:grob::stencil-height
}
\repeat unfold 300 { c'^\markup \column { a b c d e f } }
The default for TextScript.Y-extent is
grob::always-Y-extent-from-stencil, which is defined as
(output-lib.scm):
;; Using this as a callback for a grob's Y-extent promises
;; that the grob's stencil does not depend on line-spacing.
;; We use this promise to figure the space required by Clefs
;; and such at the note-spacing stage.
(define-public grob::always-Y-extent-from-stencil
(ly:make-unpure-pure-container ly:grob::stencil-height))
With just ly:grob::stencil-height, it is assumed that
the height of the grob might depend on line breaking.
Thus, it is not taken into account during page breaking.
This causes too many systems to be placed on the page.
Probably not overly helpful, but it was the best I could do...
Regards,
Jean
