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: > >> > > >> > <absent> 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.
