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

[David Wright]

On Fri 08 Jan 2021 at 15:28:25 (-0800), Aaron Hill wrote
(in a different order):
> On 2021-01-08 3:01 pm, David Wright wrote:
> > To answer your question—why not use the -dcrop option—I think
> > we are in agreement that:
> > 
> > $ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dcrop Bača.ly
> > 
> > will produce the tightly packed:
> > 
> > E   ┌──────────────┐
> >     │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
> >     │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
> >     │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
> >     └──────────────┘
> > 
> > which is what you implied you didn't want (by saying "Is this
> > supposed to happen?" and "Seems like cropping should be …").
> 
> This is clearly something that needs to be documented more clearly,
> but also we may need to reconsider what -dcrop *should* be doing
> rather than what is currently does.

Yes. I have no axe to grind/skin in the game as SVG has never been
part of my workflow, my final target being paper rather than web
pages or whatever.

> At this time, if you just want to remove the outer margins, then you
> should not be using -dcrop.  Rather, you should be manually removing
> the margins themselves within the \paper section.  Basically, make the
> virtual paper match precisely what you need, obviating the need to use
> -dcrop.

This is why, when I read the OP, and then looked at Usage, I wondered
why would one add a facility to LP itself for performing this operation.
(Not that I would fiddle with the paper size to get it to match the
output, as suggested here, but just use a tool that would do it for me.)

> It seems reasonable for folks to expect -dcrop to simply remove the
> empty margin space, which is why there is confusion that inter-system
> spacing is affected.

> The documentation makes no comment about reduced
> spacing, only that margins are to be ignored.

What's implied by 'margin' might depend on whether you're being
system-centric or page-centric. The margins of an image include
the top and bottom margins. This fact's clarity is blurred by our
having a richer vocabulary for pages: head (for headers), foot
(for footnotes), margins (for marginal notes) and gutters (empty
as concealed by the binding). So the inter-system spacing (Y-axis)
is just the lower+upper margins of two systems, corresponding
(X-axis) to the gutter, the right+left margins of a two page spread.

> What -dcrop seems to actually do is reduce each
> system to its reported extents, packing the results together while
> ignoring the paper spacing variables.

Cropping has one further effect, largely ignored here: the output
is all placed onto *one* page/image. So a side-effect of respecting
inter-system space (however it's going to be calculated) is to
further lengthen it. I had assumed that an SVG user's main concern
would be the availability of the made-up systems' stencils, and
not all the blank space in between (rather like nesting shapes
before cutting them out of a sheet of material).

> Is this a bug or not, is an
> unanswered question.

I would call it a misfeature, rather than a bug, if I didn't like it.
But, as I said, I don't know what the author's workflow might look
like, nor the OP's or anybody else's.

Cheers,
David.