Re: bookOutputName still gets "-1" suffix added to SVG file names
>> Or am I still missing the one place where that explanation is >> provided? > > It's here: > > https://lilypond.org/doc/v2.24/Documentation/usage/other-programs I've added links. https://gitlab.com/lilypond/lilypond/-/merge_requests/1901 Werner
Re: bookOutputName still gets "-1" suffix added to SVG file names
Le jeudi 30 mars 2023 à 23:09 -0600, Jeff Olson a écrit :
> Both are properly cropped, as opposed to whole (tall?) pages.
The name "-dtall-page" could perhaps be clearer. It means that all
normal pages are taken and squashed together vertically.
If you also specify -dno-use-paper-size-for-page, each page is
cropped (as opposed to having the full size of the paper),
so you effectively get cropped output.
Maybe this will be clearer to you if you compile
```
\version "2.24.1"
\header {
title = "Title"
copyright = "Copyright"
% try commenting out:
tagline = ##f
}
% try commenting out:
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'tall-page-formats 'pdf)
{ c' \break c' \pageBreak c' \pageBreak c' }
```
> Based on these limited descriptions and discussions, and my
> requirement
> for properly cropped multi-system scores in separate image files, as
> opposed to un-cropped whole pages (tall pages?), I'd still think
> separate-page-formats should work.
-dtall-page-formats does do properly cropped multi-system scores.
I'm not sure what you mean by "in separate image files". There
is one image file per \book. Or did you mean "cropped
multi-*page* scores with one image per page"? (But in that
case, you might have several SVGs/PNGs for each MIDI.)
> Or am I still missing the one place where that explanation is
> provided?
It's here:
https://lilypond.org/doc/v2.24/Documentation/usage/other-programs
signature.asc
Description: This is a digitally signed message part
Re: bookOutputName still gets "-1" suffix added to SVG file names
> Going back to the manuals didn't help explain tall-page-formats: > [...] > > Maybe the documentation of separate- and tall-page-formats > should elaborate more. This is very likely. May I invite you to provide improvements to the text? You have first-hand experience :-) Werner
Re: bookOutputName still gets "-1" suffix added to SVG file names
On 3/30/2023 7:05 PM, Jean Abou Samra wrote:
I don't understand the problem you're having. Is my suggestion of
using -dtall-page-formats not sufficient for your use case?
If you expect a 1-to-1 mapping between SVG files and MIDI files,
you can just put each piece into its own \book, with the
\bookOutputName of your choice, and compile it with
-dtall-page-formats=svg, and that should give you your desired
output files without suffixes.
Thanks, Jean.
That indeed does produce 1-to-1 mappings without suffices:
\version "2.24.1"
#(ly:set-option 'backend 'cairo)
#(ly:set-option 'tall-page-formats 'png,svg)
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'point-and-click #f)
\header { tagline = ##f }
\book {
\bookOutputName "Foo"
\score { { f' } \layout { } \midi { } }
}
\book {
\bookOutputName "Abc"
\score { { a' } \layout { } \midi { } }
}
\book {
\bookOutputName "Bar"
\score { { b' } \layout { } \midi { } }
}
Each book has a layout and a midi, with the layout rendered both
as png and svg, properly cropped and with no -1 suffix in any file names:
-rwxrwxrwx+ 1 J None 451 Mar 30 21:37 MWE-SVG-tall.ly
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37 Foo.mid
-rwxrwxrwx+ 1 J None 6498 Mar 30 21:37 Foo.svg
-rwxrwxrwx+ 1 J None 2421 Mar 30 21:37 Foo.png
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37 Abc.mid
-rwxrwxrwx+ 1 J None 6490 Mar 30 21:37 Abc.svg
-rwxrwxrwx+ 1 J None 2401 Mar 30 21:37 Abc.png
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37 Bar.mid
-rwxrwxrwx+ 1 J None 6530 Mar 30 21:37 Bar.svg
-rwxrwxrwx+ 1 J None 2377 Mar 30 21:37 Bar.png
Here is Bar.svg
Bar.svg
and Bar.png (at default low resolution of 101)
Bar.png
Both are properly cropped, as opposed to whole (tall?) pages.
I think what threw me off using tall-page-formats were conclusions on
https://lists.gnu.org/archive/html/lilypond-user/2023-03/msg00029.html
https://lists.gnu.org/archive/html/lilypond-user/2023-02/msg00070.html
https://gitlab.com/lilypond/lilypond/-/issues/6235
saying "this combination of options appears to produce cropped output"
#(ly:set-option 'separate-page-formats 'eps,png,pdf)
#(ly:set-option 'use-paper-size-for-page #f)
Going back to the manuals didn't help explain tall-page-formats:
The 2.24 usage manual defines tall-page-formats as
"Comma-separated list of formats (svg, pdf, png, or eps)
to use for the ‘tall page’ image in lilypond-book."
But I couldn't find "tall page" in the usage pages for lilypond-book
nor in the LilyPond index for either the usage manual or NR.
I did find this oblique mention near the end of the 2.24 Changes doc
(in the Miscellaneous Improvements section) regarding "the default of
the aux-files program option changed to #f" (I never use that option):
"The formats for lilypond-book images can be set separately for
the tall page image (typically PNG for HTML output) and per-system
images (typically, EPS or PDF for printed output) with the -d
sub-options -dtall-page-formats and -dseparate-page-formats
respectively."
Based on these limited descriptions and discussions, and my requirement
for properly cropped multi-system scores in separate image files, as
opposed to un-cropped whole pages (tall pages?), I'd still think
separate-page-formats should work.
Maybe the documentation of separate- and tall-page-formats
should elaborate more.
Or am I still missing the one place where that explanation is provided?
Thanks for your patience!
Jeff
Re: bookOutputName still gets "-1" suffix added to SVG file names
On 3/30/2023 10:11 AM, David Wright wrote: 32 -rwxrwxrwx+ 1 J None 32199 Mar 29 22:25 Foo-1.svg* 32 -rwxrwxrwx+ 1 J None 32190 Mar 29 22:25 Abc-1.svg* 32 -rwxrwxrwx+ 1 J None 32231 Mar 29 22:25 Bar-1.svg* That looks like a linux platform. But it's Windows 10 running the cygwin.dll (see http://cygwin.com/ and https://en.wikipedia.org/wiki/Cygwin) If the thousand-odd files are in a single directory, and you like visual interfaces, renaming them is very simple in a TUI-style file manager like Midnight Commander (mc). You'd rename (called Move) from *-1.svg to *.svg after selecting all the files with the * keystroke. If you prefer a CLI, then it's as simple as: $ cd directory-containing-files $ rename 's/-1\.svg$/.svg/' *.svg except for the complication of which version of rename you have installed on your system. I prefer the version that uses a Perl expression, and it's set up as the default on my system for the "rename" command, but can also be invoked as prename or file-rename. Where files are scattered amongst directories, the CLI rename command can be invoked from a find command, which searches directory trees for suitable filenames to rename. Cheers, David. Thanks for your detailed assistance, David! The rename command in my cygwin doesn't look like it takes Perl REs, which I'd prefer instead: $ rename -V rename from util-linux 2.33.1 SYNOPSIS rename [options] expression replacement file... DESCRIPTION rename will rename the specified files by replacing the first occurrence of expression in their name by replacement. But as this is part of my process going forward, I'll probably use bash pattern matching or write a Perl script. If it's just removing the "-1" it's easy, as you indicate. But the MidiMismatch example that I showed Jean would be more difficult. Still holding out hope that ly developers may take the suggestion I made to Jean, which would allow everything to be resolved inside ly. Thx again, Jeff
Re: bookOutputName still gets "-1" suffix added to SVG file names
Le jeudi 30 mars 2023 à 18:31 -0600, Jeff Olson a écrit :
> Understood, but, like midi, the first file could (should) still have
> been un-suffixed.
> And the current mismatch between layout files and midi files is a
> good reason for the opposite:
> Consider this MWE named MidiMismatch.ly that generates pairs of svg
> and midi files:
> \version "2.24.1"
> #(ly:set-option 'backend 'cairo)
> #(ly:set-option 'separate-page-formats 'svg)
> #(ly:set-option 'use-paper-size-for-page #f)
> #(ly:set-option 'point-and-click #f)
> \header { tagline = ##f }
> \paper { print-page-number = ##f }
> \score { { f' } \layout { } \midi { } }
> \pageBreak
> \score { { a' } \layout { } \midi { } }
> \pageBreak
> \score { { b' } \layout { } \midi { } }
> The suffices of its generated svg files are **off by one** from the
> midi files:
> 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch.mid*
> 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-1.mid*
> 1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-2.mid*
> 8 -rwxrwxrwx+ 1 J None 6496 Mar 30 17:15 MidiMismatch-1.svg*
> 8 -rwxrwxrwx+ 1 J None 6502 Mar 30 17:15 MidiMismatch-2.svg*
> 8 -rwxrwxrwx+ 1 J None 6510 Mar 30 17:15 MidiMismatch-3.svg*
I disagree that this can be considered "off by one", for two reasons.
* It only happens if you have a sequence of scores that are all
separated by a `\pageBreak`, and you separate-page-output.
Namely, you are close to trying to generate one SVG and one
MIDI file per score. Then why not just make separate \books?
* As soon as one of the scores takes more than one page, it breaks
the pairing anyway. Comparing a sequence of scores with a sequence
of pages when each score may result in several pages is
comparing apples with oranges.
> > By the way, in addition to simplifying automation (like lilypond-
> > book),
> The above example shows how this creates an automation nightmare.
That's not what I would call a nightmare. What would be a real
nightmare would be making it impossible to have separate-page
and tall-page output in the same run, doubling the compilation
time required to get all the desired outputs. Or adding the -1.svg
suffix only for the first page of separate-page output only there
is also tall-page output, which would mean you could write a working
script using separate-page output, then add tall-page output, and
it would break your previous work.
> > having -1.svg even on the first page makes it possible to use both
> > separate-page-formats and tall-page-formats at the same time.
> So I added "#(ly:set-option 'tall-page-formats 'svg)" to the example
> above
> and it produced MidiMismatch.svg (with three scores) which is what I
> assume you mean.
> It had no effect on the off-by-one between midi and svg, of course.
> Nevertheless, couldn't the suffixing algorithm in all cases still
> start with
> the un-suffixed named and add suffices only to resolve actual
> collisions?
> Removing the tall-page-formats line would then have begun with
> MidiMismatch.svg
> matching MidiMismatch.mid (the note f') and all subsequent files
> would also match.
See above for why this is not desirable in my book.
> And that would also have enabled bookOutputName in my original
> example to have
> complete control over the whole file name (with only one file per
> book).
> As it stands, it seems I'd have to use techniques outside of
> lilypond,
> as David W suggests, in order to correct the filenames. Is that
> what you're implying?
I don't understand the problem you're having. Is my suggestion of
using -dtall-page-formats not sufficient for your use case?
If you expect a 1-to-1 mapping between SVG files and MIDI files,
you can just put each piece into its own \book, with the
\bookOutputName of your choice, and compile it with
-dtall-page-formats=svg, and that should give you your desired
output files without suffixes.
The resulting SVGs will be concatenations of pages (each with
its page number for example, just all pages squashed together
in the same output file), but you can also use ly:one-page-breaking
if you want only one continuous page.
signature.asc
Description: This is a digitally signed message part
Re: bookOutputName still gets "-1" suffix added to SVG file names
On 3/29/2023 11:57 PM, Jean Abou Samra wrote:
These "-1" suffices are messing with my URLs for the SVG files,
so I'd appreciate any ideas on how to get rid of them. Thx.
They are there for good reason. If any of your |\book|s got output on
multiple pages, there would indeed be multiple files output.
Understood, but, like midi, the first file could (should) still have
been un-suffixed.
And the current mismatch between layout files and midi files is a good
reason for the opposite:
Consider this MWE named MidiMismatch.ly that generates pairs of svg and
midi files:
\version "2.24.1"
#(ly:set-option 'backend 'cairo)
#(ly:set-option 'separate-page-formats 'svg)
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'point-and-click #f)
\header { tagline = ##f }
\paper { print-page-number = ##f }
\score { { f' } \layout { } \midi { } }
\pageBreak
\score { { a' } \layout { } \midi { } }
\pageBreak
\score { { b' } \layout { } \midi { } }
The suffices of its generated svg files are **off by one** from the midi
files:
1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch.mid*
1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-1.mid*
1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-2.mid*
8 -rwxrwxrwx+ 1 J None 6496 Mar 30 17:15 MidiMismatch-1.svg*
8 -rwxrwxrwx+ 1 J None 6502 Mar 30 17:15 MidiMismatch-2.svg*
8 -rwxrwxrwx+ 1 J None 6510 Mar 30 17:15 MidiMismatch-3.svg*
By the way, in addition to simplifying automation (like lilypond-book),
The above example shows how this creates an automation nightmare.
having |-1.svg| even on the first page makes it possible to use both
|separate-page-formats| and |tall-page-formats| at the same time.
So I added "#(ly:set-option 'tall-page-formats 'svg)" to the example above
and it produced MidiMismatch.svg (with three scores) which is what I
assume you mean.
It had no effect on the off-by-one between midi and svg, of course.
Nevertheless, couldn't the suffixing algorithm in all cases still start with
the un-suffixed named and add suffices only to resolve actual collisions?
Removing the tall-page-formats line would then have begun with
MidiMismatch.svg
matching MidiMismatch.mid (the note f') and all subsequent files would
also match.
And that would also have enabled bookOutputName in my original example
to have
complete control over the whole file name (with only one file per book).
As it stands, it seems I'd have to use techniques outside of lilypond,
as David W suggests, in order to correct the filenames. Is that what
you're implying?
Thx,
Jeff
Re: bookOutputName still gets "-1" suffix added to SVG file names
On Thu 30 Mar 2023 at 07:57:23 (+0200), Jean Abou Samra wrote: > Le mercredi 29 mars 2023 à 22:56 -0600, Jeff Olson a écrit : > > I've got to generate a thousand+ cropped SVG files with specified file > > names > > from one lilypond compilation, so I'm wrapping each score in a \book with > > its own \bookOutputName as in this MWE: > > But the SVG files all have the extra -1 suffix as though there were > > additional > > files from the same book that would collide: > > > > 32 -rwxrwxrwx+ 1 J None 32199 Mar 29 22:25 Foo-1.svg* > > 32 -rwxrwxrwx+ 1 J None 32190 Mar 29 22:25 Abc-1.svg* > > 32 -rwxrwxrwx+ 1 J None 32231 Mar 29 22:25 Bar-1.svg* That looks like a linux platform. > > My MIDI files don't have this problem since they only add a suffix on > > **subsequent** files with the same base name, and there's only one per book. > > > > These "-1" suffices are messing with my URLs for the SVG files, > > so I'd appreciate any ideas on how to get rid of them. Thx. > > They are there for good reason. If any of your `\book`s got output on > multiple pages, there would indeed be multiple files output. > > If you never want separate pages, you should not use `separate-page-formats` > but `tall-page-formats`. > > By the way, in addition to simplifying automation (like lilypond-book), > having `-1.svg` even on the first page makes it possible to use both > `separate-page-formats` and `tall-page-formats` at the same time. If the thousand-odd files are in a single directory, and you like visual interfaces, renaming them is very simple in a TUI-style file manager like Midnight Commander (mc). You'd rename (called Move) from *-1.svg to *.svg after selecting all the files with the * keystroke. If you prefer a CLI, then it's as simple as: $ cd directory-containing-files $ rename 's/-1\.svg$/.svg/' *.svg except for the complication of which version of rename you have installed on your system. I prefer the version that uses a Perl expression, and it's set up as the default on my system for the "rename" command, but can also be invoked as prename or file-rename. Where files are scattered amongst directories, the CLI rename command can be invoked from a find command, which searches directory trees for suitable filenames to rename. Cheers, David.
Re: bookOutputName still gets "-1" suffix added to SVG file names
Le mercredi 29 mars 2023 à 22:56 -0600, Jeff Olson a écrit :
> I've got to generate a thousand+ cropped SVG files with specified file names
> from one lilypond compilation, so I'm wrapping each score in a \book with
> its own \bookOutputName as in this MWE:
>
> \version "2.24.1"
> #(ly:set-option 'backend 'cairo)
> #(ly:set-option 'separate-page-formats 'svg)
> #(ly:set-option 'use-paper-size-for-page #f)
> #(ly:set-option 'point-and-click #f)
> \book {
> \bookOutputName "Foo"
> { f' }
> }
> \book {
> \bookOutputName "Abc"
> { a' }
> }
> \book {
> \bookOutputName "Bar"
> { b' }
> }
>
> But the SVG files all have the extra -1 suffix as though there were
> additional
> files from the same book that would collide:
>
> 32 -rwxrwxrwx+ 1 J None 32199 Mar 29 22:25 Foo-1.svg*
> 32 -rwxrwxrwx+ 1 J None 32190 Mar 29 22:25 Abc-1.svg*
> 32 -rwxrwxrwx+ 1 J None 32231 Mar 29 22:25 Bar-1.svg*
>
> My MIDI files don't have this problem since they only add a suffix on
> **subsequent** files with the same base name, and there's only one per book.
>
> These "-1" suffices are messing with my URLs for the SVG files,
> so I'd appreciate any ideas on how to get rid of them. Thx.
They are there for good reason. If any of your `\book`s got output on multiple
pages, there would indeed be multiple files output.
If you never want separate pages, you should not use `separate-page-formats`
but `tall-page-formats`.
By the way, in addition to simplifying automation (like lilypond-book), having
`-1.svg` even on the first page makes it possible to use both
`separate-page-formats` and `tall-page-formats` at the same time.
Jean
signature.asc
Description: This is a digitally signed message part
bookOutputName still gets "-1" suffix added to SVG file names
I've got to generate a thousand+ cropped SVG files with specified file names
from one lilypond compilation, so I'm wrapping each score in a \book with
its own \bookOutputName as in this MWE:
\version "2.24.1"
#(ly:set-option 'backend 'cairo)
#(ly:set-option 'separate-page-formats 'svg)
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'point-and-click #f)
\book {
\bookOutputName "Foo"
{ f' }
}
\book {
\bookOutputName "Abc"
{ a' }
}
\book {
\bookOutputName "Bar"
{ b' }
}
But the SVG files all have the extra -1 suffix as though there were additional
files from the same book that would collide:
32 -rwxrwxrwx+ 1 J None 32199 Mar 29 22:25 Foo-1.svg*
32 -rwxrwxrwx+ 1 J None 32190 Mar 29 22:25 Abc-1.svg*
32 -rwxrwxrwx+ 1 J None 32231 Mar 29 22:25 Bar-1.svg*
My MIDI files don't have this problem since they only add a suffix on
**subsequent** files with the same base name, and there's only one per book.
These "-1" suffices are messing with my URLs for the SVG files,
so I'd appreciate any ideas on how to get rid of them. Thx.
P.S. I get the same thing using 'backend 'svg
P.P.S I'm using Windows 10 Pro with Cygnus bash and Frescobaldi 3.1.1
Jeff
