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

[David Wright]

On Wed 13 Jan 2021 at 21:01:42 (+0100), Werner LEMBERG wrote:
> >> > 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.
> >> 
> >> I vote against this.  LilyPond's behaviour is simply broken and
> >> should be corrected.  People who use struts can also easily set the
> >> staff-staff distance to zero (using the standard LilyPond paper
> >> variables).
> > 
> > I think you could be more specific about precisely which parts
> > you're unhappy with, rather than quoting the entirety and saying you
> > vote against this.
> 
> Oh, sorry, I thought it was obvious.  I vote against adding a new
> argument to `-dcrop`.

Why? The description quoted shows that an argumant is optional.

> Instead, the option should behave as expected
> and documented (i.e., having the output is on a single page with
> cropped margins, and no changes to any other vertical whitespace).

There is no "instead": it's not an either/or, but a both.
The -dcrop option would behave precisely as you required:

> -dcrop       ie #t: preserve whitespace, set as one long cropped *page*

Sorry, I should have written:

  ie #t: set as one long cropped page, preserving whitespace.

But why would you want to prevent anybody using the current
behaviour, should they so desire, by writing "-dcrop 0"?
It's quite usual to allow people to access previous behaviour
when revising software.

Cheers,
David.