> So this is an issue with manual vertical spacing in LilyPond, not wirt
lyluatex.
> Unfortunately I've never really been familiar with this, so someone else
should step in.
I'm not familiar with it neither :/
> I don't know if overriding the Y-extent of the dynamics will help here.
I've tried to look that up, but I'm lost about how to do it.
> HTH anyway
It does, thank you very much. It doesn't solve the problem, but it narrows
it down, so yeah :)
Claire
On Sun, Aug 30, 2020 at 12:09 PM Urs Liska <li...@openlilylib.org> wrote:
> So this is an issue with manual vertical spacing in LilyPond, not wirt
> lyluatex.
>
> Unfortunately I've never really been familiar with this, so someone else
> should step in.
>
> The underlying issue is that LilyPond isn't really aware of the actual
> extent of the system when cropping. This happens when you move items around
> by overridindǵ their extra-offset properties but seems an issue too ehen
> pushing around the staves themselves.
>
> I don't know if overriding the Y-extent of the dynamics will help here.
>
> ursHTH anyway
>
>
> Am Sonntag, den 30.08.2020, 11:57 +0200 schrieb Claire Meyer:
>
> Hi Urs,
>
> Huh !
> > This will give you one cropped pdf plus a number of indexed pdf files
> for each system. The cropping issues should be visible there too and might
> give some more clues for understanding the issue.
> Yep, a 100%. I attached the outputs for one system where the problem is
> visible; one from lilypond, one from lilypond + lyluatex. The cropped pdf
> with all systems has no cropping issue.
>
> Is there anything else I can provide ?
> Claire
>
> On Sun, Aug 30, 2020 at 11:26 AM Urs Liska <li...@openlilylib.org> wrote:
>
> Hi Claire,
>
> I'm not sure how the manual vertical positioning interacts with the
> cropping, but you can test further by inserting
> \include "lilypond-book-preamble.ly" in your file.
> This will give you one cropped pdf plus a number of indexed pdf files for
> each system. The cropping issues should be visible there too and might give
> some more clues for understanding the issue.
>
> The most common cause for such cropping issues would be (not in your case)
> moving stuff with extra-offset, which is then not included in the obkjects'
> X/Y-extent.
>
> Urs
>
> Am Sonntag, den 30.08.2020, 11:12 +0200 schrieb Claire Meyer:
>
> Hi all,
>
> I'm integrating a score with latex via lyluatex. The .ly file is
> finished, and gives no error; the score produced looks good, and I'm at the
> step where I just integrate with latex, and touch up the things that need
> retouching. I insert system by system, and unfortunately, some dynamics are
> mostly cropped out :
>
> [image: image.png]
> The scribble between the two systems is a dynamic mark that applies to the
> lower system. I looked in the temporary files generated by lyluatex, and
> the pdfs are cropped in such a manner that all my
> higher-placed-within-the-system dynamics are mostly removed.
>
> Those dynamics are all custom dynamic marks that I constructed like :
>
> mydyn = \tweak DynamicText.self-alignment-X #LEFT
> #(make-dynamic-script
> (markup
> #:with-dimensions '(0 . 5) '(0 . 0) #:line
> (#:normal-text #:italic "<whatever my dynamic mark says>")))
>
> They were badly placed with automatic placement (overlapping with the
> phrasing slurs, mostly), so I specified in my score for those dynamics that
> :
>
> \new Dynamics \with {
> \override VerticalAxisGroup.nonstaff-relatedstaff-spacing =
> #'((basic-distance . 6)
> (minimum-distance . 5)
> (padding . 3)
> (stretchability . 6))
> } { \dynamicsA }
>
> Any idea how to solve that problem ? I tried to include everything
> relevant to not just code dump things here, but ask away if I forgot
> something.
>
> Thanks,
> Claire
>
>
