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.
