Hi everyone,
On 13/01/2021 06:07, David Wright wrote:
On Tue 12 Jan 2021 at 09:30:05 (-0500), Trevor Bača wrote:
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:
1.
a two-measure (single-system) toy example (near the top of the page);
2.
a 17-measure minuet (near the bottom of the page); and
3.
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:
[image: screen-shot-example-2.png]
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.
A workaround that wouldn't involve changing the source code for every
multiline score would be to remove "-dcrop" from the flags list in
sphinx.py, and instead use Python's subprocess module to crop the
image with Niols's method (inkscape), shown half-a-dozen posts upthread.
The result would look like cartoon D in my earlier post (with
tagline=##f.) (My own workflow is PDF-based, and pdfcrop is the
utility I use to achieve the same result as what you want.)
This is exactly my workflow. Except I am doing OCaml and not python. I
am serving web pages containing previsualisations of tunes and I use
LilyPond to generate these previsualisations (I also use LilyPond to
generate the "end product": books of dozens of tunes under the form of a
downloadable PDF file.) Because my target is the web, I went for a
SVG-based workflow.
I looked into the -dcrop option back in the day and found myself in the
same situation as Trevor. That is when I looked for alternatives and
settled up with Inkscape to post-process the SVG generated by LilyPond.
It works nicely and has been working smoothly for years now (except when
I update to Inkscape 1.0 and had to update my command line arguments).
It is however still a bit of a shame to be doing it that way. I don't
necessarily like adding too many dependencies to my projects, and
Inkscape is a fairly big one (it is also fairly mainstream and therefore
easily present or installable on people's machines and that is why I
chose it). Moreover, since I have a pretty slow machine, this adds a
considerable amount of processing time per tune. A typical tune will
spend 13 seconds in LilyPond and then 9 extra seconds in Inkscape for
the cropping only! I could probably mitigate that by using or writing a
tool that only does the cropping of SVG, of course.
Finally, I am a bit puzzled by this -dcrop option and its removal of
inter-system space. Depending on the initial use case, this can be
intended or not. I suppose -dcrop could be made to only crop (and not
remove other kinds of spacing) or could be kept as is. In any case, this
might deserve some more words in the documentation.
Cheers,
— Niols
