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.
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. What -dcrop seems to actually do is reduce each system to its reported extents, packing the results together while ignoring the paper spacing variables. Is this a bug or not, is an unanswered question. The documentation makes no comment about reduced spacing, only that margins are to be ignored.
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.
-- Aaron Hill
