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

[David Wright]

On Wed 13 Jan 2021 at 12:11:01 (+0100), Niols wrote:
> On 13/01/2021 06:07, David Wright wrote:
> > On Tue 12 Jan 2021 at 09:30:05 (-0500), Trevor Bača wrote:
> > > 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:

[…]

> > > 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.)
> 
> This is exactly my workflow. Except I am doing OCaml and not python. I
> am serving web pages containing previsualisations of tunes and I use
> LilyPond to generate these previsualisations (I also use LilyPond to
> generate the "end product": books of dozens of tunes under the form of
> a downloadable PDF file.) Because my target is the web, I went for a
> SVG-based workflow.
> 
> I looked into the -dcrop option back in the day and found myself in
> the same situation as Trevor. That is when I looked for alternatives
> and settled up with Inkscape to post-process the SVG generated by
> LilyPond. It works nicely and has been working smoothly for years now
> (except when I update to Inkscape 1.0 and had to update my command
> line arguments).
> 
> It is however still a bit of a shame to be doing it that way. I don't
> necessarily like adding too many dependencies to my projects, and
> Inkscape is a fairly big one (it is also fairly mainstream and
> therefore easily present or installable on people's machines and that
> is why I chose it). Moreover, since I have a pretty slow machine, this
> adds a considerable amount of processing time per tune. A typical tune
> will spend 13 seconds in LilyPond and then 9 extra seconds in Inkscape
> for the cropping only! I could probably mitigate that by using or
> writing a tool that only does the cropping of SVG, of course.
> 
> Finally, I am a bit puzzled by this -dcrop option and its removal of
> inter-system space. Depending on the initial use case, this can be
> intended or not. I suppose -dcrop could be made to only crop (and not
> remove other kinds of spacing) or could be kept as is. In any case,
> this might deserve some more words in the documentation.

Perhaps the syntax and functionality of -dcrop could be extended to
include:

<absent>     ie default #f:  as now, no cropped output
-dcrop       ie #t: preserve whitespace, set as one long cropped *page*
-dcrop num   separate cropped *systems* by num mm of whitespace
             (mm is already used as the unit of eps-box-padding)

So anyone who relies on the current behaviour could just add 0 to
their -dcrop option. Transparent strut workarounds could be removed.

Cheers,
David.