Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
>> 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.
My objection is by principle. Backward compatibility doesn't make
sense to me for situations that are (a) completely buggy, and (b)
which can already be circumvented by other means.
> But why would you want to prevent anybody using the current
> behaviour, should they so desire, by writing "-dcrop 0"?
Because the natural extension of `-dcrop` is to specify margin values!
For example,
-dcrop 3
could mean that there should be a 3mm whitespace border on all sides.
As far as I can see there isn't a big difference between changing your
suggested `-dcrop` to `-dcrop 0` on the command line and putting
\paper { system-system-spacing.basic-distance = #0 }
into a file that gets added to the command line before the actual
input. In both cases you have to change something, and in both cases
it can be easily done on the command line (for most use cases) without
changing the document. If necessary, the above line can be added to
the document, which shouldn't be too much a burden either.
> It's quite usual to allow people to access previous behaviour when
> revising software.
Not for such fundamental flaws IMHO.
Werner
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
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: > >> > > >> > 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.
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
>> > Perhaps the syntax and functionality of -dcrop could be extended to >> > include: >> > >> > 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`. 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). Werner
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Wed 13 Jan 2021 at 18:29:12 (+0100), Werner LEMBERG wrote: > > > Perhaps the syntax and functionality of -dcrop could be extended to > > include: > > > > 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. Cheers, David.
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On 13/01/2021 18:29, Werner LEMBERG wrote: Perhaps the syntax and functionality of -dcrop could be extended to include: 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 thought of that. But if the argument is that some people want to generate a SVG that does not contain the spacing information, it is not helping them to replace a value by 0 but to keep the SVG file the same otherwise. That being said, I am not sure if that isn't what the current implementation of -dcrop in LilyPond is doing and I do not understand the use case of the current -dcrop option. I would tend to think that it is a broken behaviour indeed. Cheers, — Niols
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
> Perhaps the syntax and functionality of -dcrop could be extended to > include: > > 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). Werner
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Wed 13 Jan 2021 at 12:11:01 (+0100), Niols wrote: > On 13/01/2021 06:07, David Wright wrote: > > On Tue 12 Jan 2021 at 09:30:05 (-0500), Trevor Bača wrote: > > > 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: […] > > > 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. Perhaps the syntax and functionality of -dcrop could be extended to include: 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. Cheers, David.
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
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
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
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.) > 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): > > [image: local-with-whitespace.png] > > 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. Cheers, David.
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
Hi, many years ago, I asked for a -dcrop options for SVG for a very similar usecase: adding SVG images to a website (a markdown extension in particular). It was then implemented some time later and I was happy with it (with my single line scores). It might be that Étienne Beaulé implemented it, but that is just a guess from a distant memory - git could surely tell. I am writing that here, because I’d like to add that as far as I remember, the intention for -dcrop was like Trevor explained and the removal of inter-system white-space seems like an accident to me. Cheers, Joram
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
> In the upcoming release of Abjad’s docs, my workaround has been to > add transparent markup “struts” above notes in the top system, [...] Nice idea! For multi-system cropped output this is a good temporary workaround IMHO. > Knowing all this, would it be possible to allow for a > non-system-packing version of -dcrop? I hope that some of the more powerful LilyPond developers find time and interest to fix this in the not too distant future. You might help us with submitting a bug report, BTW – it seems that the problem has been discussed on the mailing list(s) but I can't find something related in lilypond's issue database. Werner
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Fri, Jan 8, 2021 at 6:02 PM David Wright wrote: > On Thu 07 Jan 2021 at 19:57:12 (-0500), Trevor Bača wrote: > > On Wed, Jan 6, 2021 at 2:29 PM David Wright wrote: > > > On Wed 06 Jan 2021 at 11:34:24 (-0500), Trevor Bača wrote: > > > > On Tue, Jan 5, 2021 at 11:31 PM David Wright wrote: > > > > > On Tue 05 Jan 2021 at 19:05:30 (-0500), Trevor Bača wrote: > > > > > > I love the functionality for cropped SVGs! (Added back in 2019, > or > > > > > > around then?) > > > > > > > > > > > > Question: it appears that cropped multisystem SVGs remove all > > > > > > whitespace between systems. Is this supposed to happen? > > > > > > > > > > I think that removing all the margins is the functionality "crop" > is > > > > > supposed to add to LP. To generate the equivalent cropped and > packed > > > > > image without this facility would be quite tedious to do (unless > > > > > someone has a trick for doing it?). > > > > > > > > > > > %%% BEGIN %%% > > > > > > […] > > > > > > %%% END %%% > > > > > > > > > > > > Called with ... > > > > > >lilypond -dbackend=svg -dcrop test.ly > > > > > > ... produces test.cropped.svg as attached here. > > > > > > > > > > > > Screenshot: > > > > > > […] > > > > > > > > > > > > Seems like cropping should be around the edges of the image > (rather > > > > > > than between systems)? > > > > > > > > > > If you just want to crop the whole page image, you can do that > easily > > > > > at the end of a normal run with the usual utilities. If you require > > > > > LP to set the entire score on a single page, just use a very long > > > > > custom page (as in NR §4.1.2: width, then length). > > > > > > > > I'm sorry; I don't understand. > > > > > > > > What I want Lily to do: remove whitespace from the *edges* of an SVG. > > > > > > As I said, you run LP as normal, and then trim to taste. So, taking > > > your example, I ran it with > > > $ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dno-point-and-click > > > Bača.ly > > > and then edited the first line of Bača.svg, resulting in > Bača-trimmed.svg. > > > The end of the first line is modified from > > > width="210.00mm" height="297.00mm" viewBox="0 0 119.5016 169.0094"> > > > to > > > width="192.00mm" height="297.00mm" viewBox="4.5 0 109.5016 169.0094"> > > > which I did by inspection. As you use SVG files in your workflow, > > > I assume you can carry this out more easily and precisely¹ with some > > > particular tool. (I'm PDF-centric myself.) I only considered X because > > > I was inspecting the file on a landscape screen (and you didn't remove > > > the tagline anyway). > > > > > > > What Lily actually does when -dcrop is set: removes whitespace from > the > > > > edges *and from between all systems* of an SVG. > > > > > > That's right, so that your file contains all the information, > > > unencumbered by margins, ready for some sort of further processing. > > > Obviously, I don't know what that will be in your case. > > > > > > It reminds me of those PNG files that you find in browsers' cache, > > > which have a strip or grid of little images that are used internally, > > > either as a toolbar, or displayed sequentially like a movie. > > > > > > > So my question is: is Lily supposed to remove whitespace from > *between* > > > > systems when -d[c]rop is set? > > > > > > AIUI yes. But this is policy: I await pronouncements from higher-ups. > > > > > > ¹ I believe the modifications need to be kept proportional, in order > > > to preserve the aspect ratio. > > > > I really appreciate the responses, but I'm even more confused than > before. > > > > When you ran ... > > > > $ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dno-point-and-click > Bača.ly > > > > ... why didn't you include the -dcrop option? > > [You need a fixed width font to make sense of text below.] > > What running my command on your source produces might be represented by: > > A ┌┐ > ││ > ││ > │⸱⸱⸱▒▒⸱⸱⸱│ > ││ > │⸱⸱⸱▒▒⸱⸱⸱│ > ││ > │⸱⸱⸱▒▒⸱⸱⸱│ > ││ > ││ > ││ > ││ > ││ > ││ > │⸱tt⸱│ > ││ > └┘ > > where ⸱ is white space, ▒ is music, and t is the tagline. > > What my previous post also had attached to it was the result of > trimming off the whitespace from just the sides: > > B ┌──┐ > │⸱⸱│ > │⸱⸱│ > │▒▒│ > │⸱⸱│ > │▒▒│ > │⸱⸱│ > │▒▒│ > │⸱⸱│ > │⸱⸱│ > │⸱⸱│ > │⸱⸱│ > │⸱⸱│ > │⸱⸱│ > │⸱⸱tt⸱⸱│ > │⸱⸱│ > └──┘ > > (I trimmed only the sides because the i
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
>> 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 boolIf 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. Werner
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Sat 09 Jan 2021 at 07:31:19 (+0100), Werner LEMBERG wrote: > >> $ 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. > > 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 boolIf bool is #t, fit all the music and headers, without margins, into a ‘single-page’ output file. Default: #f. So I certainly agree that it needs clarification as to whether "music" means *systems* or *made-up pages*. Cheers, David.
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
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.
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
>> $ 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. 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. Werner
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
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
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Thu 07 Jan 2021 at 19:57:12 (-0500), Trevor Bača wrote: > On Wed, Jan 6, 2021 at 2:29 PM David Wright wrote: > > On Wed 06 Jan 2021 at 11:34:24 (-0500), Trevor Bača wrote: > > > On Tue, Jan 5, 2021 at 11:31 PM David Wright wrote: > > > > On Tue 05 Jan 2021 at 19:05:30 (-0500), Trevor Bača wrote: > > > > > I love the functionality for cropped SVGs! (Added back in 2019, or > > > > > around then?) > > > > > > > > > > Question: it appears that cropped multisystem SVGs remove all > > > > > whitespace between systems. Is this supposed to happen? > > > > > > > > I think that removing all the margins is the functionality "crop" is > > > > supposed to add to LP. To generate the equivalent cropped and packed > > > > image without this facility would be quite tedious to do (unless > > > > someone has a trick for doing it?). > > > > > > > > > %%% BEGIN %%% > > > > > […] > > > > > %%% END %%% > > > > > > > > > > Called with ... > > > > >lilypond -dbackend=svg -dcrop test.ly > > > > > ... produces test.cropped.svg as attached here. > > > > > > > > > > Screenshot: > > > > > […] > > > > > > > > > > Seems like cropping should be around the edges of the image (rather > > > > > than between systems)? > > > > > > > > If you just want to crop the whole page image, you can do that easily > > > > at the end of a normal run with the usual utilities. If you require > > > > LP to set the entire score on a single page, just use a very long > > > > custom page (as in NR §4.1.2: width, then length). > > > > > > I'm sorry; I don't understand. > > > > > > What I want Lily to do: remove whitespace from the *edges* of an SVG. > > > > As I said, you run LP as normal, and then trim to taste. So, taking > > your example, I ran it with > > $ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dno-point-and-click > > Bača.ly > > and then edited the first line of Bača.svg, resulting in Bača-trimmed.svg. > > The end of the first line is modified from > > width="210.00mm" height="297.00mm" viewBox="0 0 119.5016 169.0094"> > > to > > width="192.00mm" height="297.00mm" viewBox="4.5 0 109.5016 169.0094"> > > which I did by inspection. As you use SVG files in your workflow, > > I assume you can carry this out more easily and precisely¹ with some > > particular tool. (I'm PDF-centric myself.) I only considered X because > > I was inspecting the file on a landscape screen (and you didn't remove > > the tagline anyway). > > > > > What Lily actually does when -dcrop is set: removes whitespace from the > > > edges *and from between all systems* of an SVG. > > > > That's right, so that your file contains all the information, > > unencumbered by margins, ready for some sort of further processing. > > Obviously, I don't know what that will be in your case. > > > > It reminds me of those PNG files that you find in browsers' cache, > > which have a strip or grid of little images that are used internally, > > either as a toolbar, or displayed sequentially like a movie. > > > > > So my question is: is Lily supposed to remove whitespace from *between* > > > systems when -d[c]rop is set? > > > > AIUI yes. But this is policy: I await pronouncements from higher-ups. > > > > ¹ I believe the modifications need to be kept proportional, in order > > to preserve the aspect ratio. > > I really appreciate the responses, but I'm even more confused than before. > > When you ran ... > > $ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dno-point-and-click Bača.ly > > ... why didn't you include the -dcrop option? [You need a fixed width font to make sense of text below.] What running my command on your source produces might be represented by: A ┌┐ ││ ││ │⸱⸱⸱▒▒⸱⸱⸱│ ││ │⸱⸱⸱▒▒⸱⸱⸱│ ││ │⸱⸱⸱▒▒⸱⸱⸱│ ││ ││ ││ ││ ││ ││ │⸱tt⸱│ ││ └┘ where ⸱ is white space, ▒ is music, and t is the tagline. What my previous post also had attached to it was the result of trimming off the whitespace from just the sides: B ┌──┐ │⸱⸱│ │⸱⸱│ │▒▒│ │⸱⸱│ │▒▒│ │⸱⸱│ │▒▒│ │⸱⸱│ │⸱⸱│ │⸱⸱│ │⸱⸱│ │⸱⸱│ │⸱⸱│ │⸱⸱tt⸱⸱│ │⸱⸱│ └──┘ (I trimmed only the sides because the image was taller than my screen, which made it difficult to inspect the entire image in the Y direction.) Then Niols posted inkscape command lines to produce: C ┌──┐ │▒▒│ │⸱⸱│ │▒▒│ │⸱⸱│ │▒▒│ │⸱⸱│ │⸱
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Wed, Jan 6, 2021 at 2:29 PM David Wright wrote: > On Wed 06 Jan 2021 at 11:34:24 (-0500), Trevor Bača wrote: > > On Tue, Jan 5, 2021 at 11:31 PM David Wright wrote: > > > On Tue 05 Jan 2021 at 19:05:30 (-0500), Trevor Bača wrote: > > > > I love the functionality for cropped SVGs! (Added back in 2019, or > around > > > > then?) > > > > > > > > Question: it appears that cropped multisystem SVGs remove all > whitespace > > > > between systems. Is this supposed to happen? > > > > > > I think that removing all the margins is the functionality "crop" is > > > supposed to add to LP. To generate the equivalent cropped and packed > > > image without this facility would be quite tedious to do (unless > > > someone has a trick for doing it?). > > > > > > > %%% BEGIN %%% > > > > […] > > > > %%% END %%% > > > > > > > > Called with ... > > > >lilypond -dbackend=svg -dcrop test.ly > > > > ... produces test.cropped.svg as attached here. > > > > > > > > Screenshot: > > > > […] > > > > > > > > Seems like cropping should be around the edges of the image (rather > than > > > > between systems)? > > > > > > If you just want to crop the whole page image, you can do that easily > > > at the end of a normal run with the usual utilities. If you require > > > LP to set the entire score on a single page, just use a very long > > > custom page (as in NR §4.1.2: width, then length). > > > > I'm sorry; I don't understand. > > > > What I want Lily to do: remove whitespace from the *edges* of an SVG. > > As I said, you run LP as normal, and then trim to taste. So, taking > your example, I ran it with > $ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dno-point-and-click > Bača.ly > and then edited the first line of Bača.svg, resulting in Bača-trimmed.svg. > The end of the first line is modified from > width="210.00mm" height="297.00mm" viewBox="0 0 119.5016 169.0094"> > to > width="192.00mm" height="297.00mm" viewBox="4.5 0 109.5016 169.0094"> > which I did by inspection. As you use SVG files in your workflow, > I assume you can carry this out more easily and precisely¹ with some > particular tool. (I'm PDF-centric myself.) I only considered X because > I was inspecting the file on a landscape screen (and you didn't remove > the tagline anyway). > > > What Lily actually does when -dcrop is set: removes whitespace from the > > edges *and from between all systems* of an SVG. > > That's right, so that your file contains all the information, > unencumbered by margins, ready for some sort of further processing. > Obviously, I don't know what that will be in your case. > > It reminds me of those PNG files that you find in browsers' cache, > which have a strip or grid of little images that are used internally, > either as a toolbar, or displayed sequentially like a movie. > > > So my question is: is Lily supposed to remove whitespace from *between* > > systems when -d[c]rop is set? > > AIUI yes. But this is policy: I await pronouncements from higher-ups. > > ¹ I believe the modifications need to be kept proportional, in order > to preserve the aspect ratio. > Hi David, I really appreciate the responses, but I'm even more confused than before. When you ran ... $ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dno-point-and-click Bača.ly ... why didn't you include the -dcrop option? -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
Hello, On 06/01/2021 20:29, David Wright wrote: On Wed 06 Jan 2021 at 11:34:24 (-0500), Trevor Bača wrote: What I want Lily to do: remove whitespace from the *edges* of an SVG. As I said, you run LP as normal, and then trim to taste. So, taking your example, I ran it with $ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dno-point-and-click Bača.ly and then edited the first line of Bača.svg, resulting in Bača-trimmed.svg. The end of the first line is modified from width="210.00mm" height="297.00mm" viewBox="0 0 119.5016 169.0094"> to width="192.00mm" height="297.00mm" viewBox="4.5 0 109.5016 169.0094"> which I did by inspection. As you use SVG files in your workflow, I assume you can carry this out more easily and precisely¹ with some particular tool. (I'm PDF-centric myself.) I only considered X because I was inspecting the file on a landscape screen (and you didn't remove the tagline anyway). In term of particular tool, I personnaly use Inkscape for this task. This is probably far from optimal but it works nicely. For Inkscape < 1.0, the following: inkscape --without-gui --export-area-drawing --export-plain-svg=output.cropped.svg input.svg For Inkscape >= 1.0, the following: inkscape --export-area-drawing --export-plain-svg --export-filename=output.cropped.svg input.svg or in short: inkscape -Dlo output.cropped.svg input.svg I suppose there might be faster lighter tools for that and I would love to hear from them. Best, — Niols
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Wed 06 Jan 2021 at 11:34:24 (-0500), Trevor Bača wrote:
> On Tue, Jan 5, 2021 at 11:31 PM David Wright wrote:
> > On Tue 05 Jan 2021 at 19:05:30 (-0500), Trevor Bača wrote:
> > > I love the functionality for cropped SVGs! (Added back in 2019, or around
> > > then?)
> > >
> > > Question: it appears that cropped multisystem SVGs remove all whitespace
> > > between systems. Is this supposed to happen?
> >
> > I think that removing all the margins is the functionality "crop" is
> > supposed to add to LP. To generate the equivalent cropped and packed
> > image without this facility would be quite tedious to do (unless
> > someone has a trick for doing it?).
> >
> > > %%% BEGIN %%%
> > > […]
> > > %%% END %%%
> > >
> > > Called with ...
> > >lilypond -dbackend=svg -dcrop test.ly
> > > ... produces test.cropped.svg as attached here.
> > >
> > > Screenshot:
> > > […]
> > >
> > > Seems like cropping should be around the edges of the image (rather than
> > > between systems)?
> >
> > If you just want to crop the whole page image, you can do that easily
> > at the end of a normal run with the usual utilities. If you require
> > LP to set the entire score on a single page, just use a very long
> > custom page (as in NR §4.1.2: width, then length).
>
> I'm sorry; I don't understand.
>
> What I want Lily to do: remove whitespace from the *edges* of an SVG.
As I said, you run LP as normal, and then trim to taste. So, taking
your example, I ran it with
$ lilypond-2.21.80-1.linux-64/bin/lilypond --svg -dno-point-and-click Bača.ly
and then edited the first line of Bača.svg, resulting in Bača-trimmed.svg.
The end of the first line is modified from
width="210.00mm" height="297.00mm" viewBox="0 0 119.5016 169.0094">
to
width="192.00mm" height="297.00mm" viewBox="4.5 0 109.5016 169.0094">
which I did by inspection. As you use SVG files in your workflow,
I assume you can carry this out more easily and precisely¹ with some
particular tool. (I'm PDF-centric myself.) I only considered X because
I was inspecting the file on a landscape screen (and you didn't remove
the tagline anyway).
> What Lily actually does when -dcrop is set: removes whitespace from the
> edges *and from between all systems* of an SVG.
That's right, so that your file contains all the information,
unencumbered by margins, ready for some sort of further processing.
Obviously, I don't know what that will be in your case.
It reminds me of those PNG files that you find in browsers' cache,
which have a strip or grid of little images that are used internally,
either as a toolbar, or displayed sequentially like a movie.
> So my question is: is Lily supposed to remove whitespace from *between*
> systems when -d[c]rop is set?
AIUI yes. But this is policy: I await pronouncements from higher-ups.
¹ I believe the modifications need to be kept proportional, in order
to preserve the aspect ratio.
Cheers,
David.
\paper
{
system-system-spacing.minimum-distance = #20
}
\new Score {
c'1
\break
c'1
\break
c'1
}
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Tue, Jan 5, 2021 at 11:31 PM David Wright wrote: > On Tue 05 Jan 2021 at 19:05:30 (-0500), Trevor Bača wrote: > > I love the functionality for cropped SVGs! (Added back in 2019, or around > > then?) > > > > Question: it appears that cropped multisystem SVGs remove all whitespace > > between systems. Is this supposed to happen? > > I think that removing all the margins is the functionality "crop" is > supposed to add to LP. To generate the equivalent cropped and packed > image without this facility would be quite tedious to do (unless > someone has a trick for doing it?). > > > %%% BEGIN %%% > > […] > > %%% END %%% > > > > Called with ... > >lilypond -dbackend=svg -dcrop test.ly > > ... produces test.cropped.svg as attached here. > > > > Screenshot: > > […] > > > > Seems like cropping should be around the edges of the image (rather than > > between systems)? > > If you just want to crop the whole page image, you can do that easily > at the end of a normal run with the usual utilities. If you require > LP to set the entire score on a single page, just use a very long > custom page (as in NR §4.1.2: width, then length). > I'm sorry; I don't understand. What I want Lily to do: remove whitespace from the *edges* of an SVG. What Lily actually does when -dcrop is set: removes whitespace from the edges *and from between all systems* of an SVG. So my question is: is Lily supposed to remove whitespace from *between* systems when -drop is set? -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca
Re: Why does -dbackend=svg -dcrop remove system-system-spacing?
On Tue 05 Jan 2021 at 19:05:30 (-0500), Trevor Bača wrote: > I love the functionality for cropped SVGs! (Added back in 2019, or around > then?) > > Question: it appears that cropped multisystem SVGs remove all whitespace > between systems. Is this supposed to happen? I think that removing all the margins is the functionality "crop" is supposed to add to LP. To generate the equivalent cropped and packed image without this facility would be quite tedious to do (unless someone has a trick for doing it?). > %%% BEGIN %%% > […] > %%% END %%% > > Called with ... >lilypond -dbackend=svg -dcrop test.ly > ... produces test.cropped.svg as attached here. > > Screenshot: > […] > > Seems like cropping should be around the edges of the image (rather than > between systems)? If you just want to crop the whole page image, you can do that easily at the end of a normal run with the usual utilities. If you require LP to set the entire score on a single page, just use a very long custom page (as in NR §4.1.2: width, then length). Cheers, David.
