Re: Why does -dbackend=svg -dcrop remove system-system-spacing?

[David Wright]

On Tue 12 Jan 2021 at 09:30:05 (-0500), Trevor Bača wrote:
> Hi Werner, Aaron and David (again),
> 
> I’m the OP, and I realize that I failed to provide the context of my
> workflow. I’ll try to do that now, to help make better use of all your time!
> 
> My workflow has to do with maintaining the docs for Abjad. (Abjad is a
> Python package for generating LilyPond files programmatically.) I’ve used
> Lily for years to produce (PDF output of) my own scores, which never
> involved cropping. More recently, documentation of examples on the Abjad
> website has necessitated cropping. Here’s an example of a minuet-generating
> game from the 18th-century, sometimes attributed to Mozart:
> 
> https://abjad.github.io/literature_examples/mozart.html
> 
> That page contains three examples created by LilyPond:
> 
>    1.
> 
>    a two-measure (single-system) toy example (near the top of the page);
>    2.
> 
>    a 17-measure minuet (near the bottom of the page); and
>    3.
> 
>    the same 17-measure minuet with a few more overrides (at the very bottom
>    of the page).
> 
> You can right away the quality of Lily’s SVG output for these examples is
> fantastic. Lily’s SVG images have added a new level of professionalism to
> my docs.
> 
> But you can also see the multisystem examples (#2 and #3) look kinda crazy
> because of the “system-packing” trait carried by the current implementation
> of -dcrop:
> 
> [image: screen-shot-example-2.png]
> 
> There’s just not enough whitespace between systems. And it would be so
> lovely to bring the whole thing up to the beautiful standards that are now
> possible with the sharpness of the SVG output. (And the bass clef hasn’t
> been attached yet in that example! ;)
> 
> In the upcoming release of Abjad’s docs, my workaround has been to add
> transparent markup “struts” above notes in the top system, sprinkling
> something like …
> 
>   - \tweak staff-padding #10
>   - \tweak transparent ##t
>   ^ \markup A
> 
> … at strategic places.

A workaround that wouldn't involve changing the source code for every
multiline score would be to remove "-dcrop" from the flags list in
sphinx.py, and instead use Python's subprocess module to crop the
image with Niols's method (inkscape), shown half-a-dozen posts upthread.

The result would look like cartoon D in my earlier post (with
tagline=##f.) (My own workflow is PDF-based, and pdfcrop is the
utility I use to achieve the same result as what you want.)

> Surprisingly, the presence of the (transparent)
> markup tricks -dcrop into preserving the whitespace between systems, giving
> totally beautiful results. Here’s an example (local to my machine and not
> yet visible at the link above):
> 
> [image: local-with-whitespace.png]
> 
> Ok, apologies for going on at length here, but hopefully now my workflow is
> a little more clear.
> 
> I’m not here to condemn the implementation of a feature (or anyone’s
> work!). I was just surprised that -dcrop “packs” systems together, because
> that’s not a behavior of cropping I'm used to in other pieces of software.
> And the “system packing” behavior of the current implementation of -dcrop
> means that in the Abjad docs I have really wonderful single-system examples
> … but messier multisystem examples.
> 
> In the end, I guess all of this reduces to the following: the current
> (“system-packing”) trait of -dcrop means that my multisystem examples are
> less than ideal. That’s all ;)
> 
> Knowing all this, would it be possible to allow for a non-system-packing
> version of -dcrop?
> 
> Only because I have hard time imagining a use case for the current
> system-packing behavior, I suppose it’s possible that the behavior of
> -dcrop should be changed globally to preserve intersystem spacing. (“Why
> would we want to remove an element of page layout that users specify by
> hand, with system-system-spacing and the like?”) But maybe there are users
> with creative uses of the current system-packing behavior? In which case
> I’d be delighted with perhaps an additional flag (-dcrop-preserve?) to
> allow page-layout-preserving cases, too.
> 
> Either outcome opens up a new world of possibilities in which users can use
> SVG output to demo the page layout of music, cropped to fit nicely into doc
> websites and the like.

Cheers,
David.