On Mon, Jan 11, 2021 at 5:50 PM Werner LEMBERG wl@gnu.org wrote:
>> For me, it's a bug, mainly because the behaviour is completely
>> unexpected. Also, `-dhelp` says
>>
>> crop (#f) Match the size of the normal output to the
>> typeset image.
>>
>> which differs from the reality. Note the words 'normal output'.
>> Removing inter-line spacing between staves is definitely not normal
>> output.
>
> I'd missed that. I only looked at the Usage manual:
>
> crop bool If bool is #t, fit all the music and headers, without
> margins, into a ‘single-page’ output file. Default: #f.
Well, it's a buglet by itself that this info differs from what
`-dhelp` gives. It essentially says that the music gets output to a
single page that can become arbitrarily long. Again, there is zero
reason to remove the vertical inter-staff space.
BTW, the documentation misses to mention that a PNG image gets created
in addition to a PDF. It's also missing that the cropped PDF file and
its PNG rendering output have the suffixes `.cropped.pdf` and
`.cropped.png` by default, respectively, and that those files are
created in addition to a normal PDF output file. See MR !605 for a
fix.
> So I certainly agree that it needs clarification as to whether
> "music" means *systems* or *made-up pages*.
I don't understand what you want to say. Please clarify.
Hi Werner, Aaron and David (again),
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:
https://abjad.github.io/literature_examples/mozart.html
That page contains three examples created by LilyPond:
a two-measure (single-system) toy example (near the top of the page);
a 17-measure minuet (near the bottom of the page); and
the same 17-measure minuet with a few more overrides (at the very bottom of the page).
You can right away the quality of Lily’s SVG output for these examples is fantastic. Lily’s SVG images have added a new level of professionalism to my docs.
But you can also see the multisystem examples (#2 and #3) look kinda crazy because of the “system-packing” trait carried by the current implementation of -dcrop:
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. Surprisingly, the presence of the (transparent) markup tricks -dcrop into preserving the whitespace between systems, giving totally beautiful results. Here’s an example (local to my machine and not yet visible at the link above):
Ok, apologies for going on at length here, but hopefully now my workflow is a little more clear.
I’m not here to condemn the implementation of a feature (or anyone’s work!). I was just surprised that -dcrop “packs” systems together, because that’s not a behavior of cropping I'm used to in other pieces of software. And the “system packing” behavior of the current implementation of -dcrop means that in the Abjad docs I have really wonderful single-system examples … but messier multisystem examples.
In the end, I guess all of this reduces to the following: the current (“system-packing”) trait of -dcrop means that my multisystem examples are less than ideal. That’s all ;)
Knowing all this, would it be possible to allow for a non-system-packing version of -dcrop?
Only because I have hard time imagining a use case for the current system-packing behavior, I suppose it’s possible that the behavior of -dcrop should be changed globally to preserve intersystem spacing. (“Why would we want to remove an element of page layout that users specify by hand, with system-system-spacing and the like?”) But maybe there are users with creative uses of the current system-packing behavior? In which case I’d be delighted with perhaps an additional flag (-dcrop-preserve?) to allow page-layout-preserving cases, too.
Either outcome opens up a new world of possibilities in which users can use SVG output to demo the page layout of music, cropped to fit nicely into doc websites and the like.
Trevor.