Lots of temporary files when generating png files

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Lots of temporary files when generating png files

Anthony Rushforth
Hello,

I use this command line to generate png files :
lilypond  -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts -dpixmap-format=pngalpha -dresolution=100 --png c1c1e1g1.ly


It generates these files :
c1c1e1g1-1.eps
c1c1e1g1-systems.count
c1c1e1g1-systems.tex
c1c1e1g1-systems.texi
c1c1e1g1.eps


Is it possible to avoid these files or put them in another location ?




c1c1e1g1.ly (434 bytes) Download Attachment
c1c1e1g1.png (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

Mark Knoop-4
At 10:25 on 04 Feb 2020, Anthony Rushforth wrote:

> Hello,
>
> I use this command line to generate png files :
> lilypond  -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts
> -dpixmap-format=pngalpha -dresolution=100 --png c1c1e1g1.ly
>
> I took the command line from
> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#lilypond-output-in-other-programs
>
> It generates these files :
> c1c1e1g1-1.eps
> c1c1e1g1-systems.count
> c1c1e1g1-systems.tex
> c1c1e1g1-systems.texi
> c1c1e1g1.eps
>
> Is it possible to avoid these files or put them in another location ?

-dno-aux-files will get rid of most, although not the ...-1.eps file.

--
Mark Knoop

Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

Anthony Rushforth
Thank you ! I searched a lot but did not find this option.

There's only one eps remaining (c1c1e1g1.eps in my example), the other ones don't appear (including c1c1e1g1-1.eps).

I'll add a "delete" in the calling program...

Thanks again



Le mar. 4 févr. 2020 à 11:46, Mark Knoop <[hidden email]> a écrit :
At 10:25 on 04 Feb 2020, Anthony Rushforth wrote:
> Hello,
>
> I use this command line to generate png files :
> lilypond  -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts
> -dpixmap-format=pngalpha -dresolution=100 --png c1c1e1g1.ly
>
> I took the command line from
> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#lilypond-output-in-other-programs
>
> It generates these files :
> c1c1e1g1-1.eps
> c1c1e1g1-systems.count
> c1c1e1g1-systems.tex
> c1c1e1g1-systems.texi
> c1c1e1g1.eps
>
> Is it possible to avoid these files or put them in another location ?

-dno-aux-files will get rid of most, although not the ...-1.eps file.

--
Mark Knoop

Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

David Wright
In reply to this post by Mark Knoop-4
On Tue 04 Feb 2020 at 10:44:56 (+0000), Mark Knoop wrote:

> At 10:25 on 04 Feb 2020, Anthony Rushforth wrote:
> >
> > I use this command line to generate png files :
> > lilypond  -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts
> > -dpixmap-format=pngalpha -dresolution=100 --png c1c1e1g1.ly
> >
> > I took the command line from
> > http://lilypond.org/doc/v2.19/Documentation/usage-big-page#lilypond-output-in-other-programs
> >
> > It generates these files :
> > c1c1e1g1-1.eps
> > c1c1e1g1-systems.count
> > c1c1e1g1-systems.tex
> > c1c1e1g1-systems.texi
> > c1c1e1g1.eps
> >
> > Is it possible to avoid these files or put them in another location ?
>
> -dno-aux-files will get rid of most, although not the ...-1.eps file.

I prefer to generate such files and "trash" them at the end of a
successful run (by moving them to a directory under /tmp).
I don't know what system you're using, but it's straightforward in
linux to write a script to run LP that does this for you, and saves
you a lot of typing in the command line.

Not using PNG files, I don't have your particular problem, but my
script tees the console output into a .log file. If the file contains
the string "ERROR", the .log file is renamed .error and kept, whereas
otherwise the .log file is "trashed".

An example where I do have your problem is with pdflatex, which not
only writes .aux and .log files, but leaves them world-writeable.
(Maybe it's been fixed—I don't bother checking.) Here, it's
important not to actually delete the .aux file, because it's required
for final production of documents that have TOCs or forward references
etc, but it's not needed in 99% of my pdflatex runs.

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

Aaron Hill
In reply to this post by Anthony Rushforth
On 2020-02-04 6:07 am, Anthony Rushforth wrote:
> There's only one eps remaining (c1c1e1g1.eps in my example), the other
> ones
> don't appear (including c1c1e1g1-1.eps).
>
> Le mar. 4 févr. 2020 à 11:46, Mark Knoop <[hidden email]> a écrit :
>> At 10:25 on 04 Feb 2020, Anthony Rushforth wrote:
>> > I use this command line to generate png files :
>> > lilypond  -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts
>> > -dpixmap-format=pngalpha -dresolution=100 --png c1c1e1g1.ly

Why use -dbackend=eps at all?  There seems to be some spurious options
in there.

I generate transparent PNGs all the time and never have to deal with
extra files.

Here is my command-line:

####
lilypond \
   -dresolution=288 \
   -dpixmap-format=pngalpha \
   --png \
   source.ly
####


-- Aaron Hill

Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

Anthony Rushforth
@Aaron : Because if I use your command line I get this png : a full page

I want a cropped png, and I found the command line I use in the documentation (http://lilypond.org/doc/v2.19/Documentation/usage-big-page#lilypond-output-in-other-programs) :

To produce ‘PNG’ images;

lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png myfile.ly

I don't understand why it has to be "eps", but it's the only way I found... do you have another option to get cropped images ?

@David : I'm writing a program that generates html files including images with lilypond scores.
My first attempt was using "lilypond-book" but I need more control (I want to include midi file for example).
I will delete the remaining EPS file from my program.

Regards,
Anthony


Le mar. 4 févr. 2020 à 15:37, Aaron Hill <[hidden email]> a écrit :
On 2020-02-04 6:07 am, Anthony Rushforth wrote:
> There's only one eps remaining (c1c1e1g1.eps in my example), the other
> ones
> don't appear (including c1c1e1g1-1.eps).
>
> Le mar. 4 févr. 2020 à 11:46, Mark Knoop <[hidden email]> a écrit :
>> At 10:25 on 04 Feb 2020, Anthony Rushforth wrote:
>> > I use this command line to generate png files :
>> > lilypond  -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts
>> > -dpixmap-format=pngalpha -dresolution=100 --png c1c1e1g1.ly

Why use -dbackend=eps at all?  There seems to be some spurious options
in there.

I generate transparent PNGs all the time and never have to deal with
extra files.

Here is my command-line:

####
lilypond \
   -dresolution=288 \
   -dpixmap-format=pngalpha \
   --png \
   source.ly
####


-- Aaron Hill


c1c1e1g1.png (61K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

Aaron Hill
On 2020-02-04 7:59 am, Anthony Rushforth wrote:

> @Aaron : Because if I use your command line I get this png : a full
> page
>
> I want a cropped png, and I found the command line I use in the
> documentation (
> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#lilypond-output-in-other-programs)
> :
>
>> To produce ‘PNG’ images;
>>
>> lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png
>> myfile.ly
>>
>>
> I don't understand why it has to be "eps", but it's the only way I
> found...
> do you have another option to get cropped images ?
Two options: (1) fix your \paper settings, or (2) use the crop feature
of LilyPond.

Regarding the first option, the idea is to set up your \paper properly
so that the output from LilyPond is what you want.  My use case involves
outputting transparent PNGs for use in projection.  I have my paper size
configured to match the slides, and I have adjusted staff and font sizes
accordingly to try to maintain good readability.  In this way, the
output from LilyPond is nearly perfect for dropping into a presentation.
  I only need to use ImageMagick for a little post-processing, which does
include cropping transparent pixels, since some slides are not as "full"
as others.  For reference, here is an excerpt from my build script
showing the IM command-line:

####
./imagemagick/magick convert $file -trim +repage \
   -filter Spline -define filter:blur=0.707 \
   -distort Resize 50% -density 56.69 PNG32:$file
####


Regarding the second option, LilyPond provides a built-in form of
cropping.  The amended command-line would look as follows:

####
lilypond \
   -dcrop -dno-print-pages \
   -dresolution=288 \
   -dpixmap-format=pngalpha \
   --png \
   source.ly
####

Note that -dno-print-pages is used to suppress the normal output.

I went the IM route because -dcrop does change how LilyPond handles
vertical spacing.  Depending on your needs, you might find -dcrop works
well enough.


-- Aaron Hill

c1c1e1g1.png (61K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

David Wright
In reply to this post by Anthony Rushforth
On Tue 04 Feb 2020 at 16:59:36 (+0100), Anthony Rushforth wrote:

> @Aaron : Because if I use your command line I get this png : a full page
>
> I want a cropped png, and I found the command line I use in the
> documentation (
> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#lilypond-output-in-other-programs)
> :
>
> > To produce ‘PNG’ images;
> >
> > lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png myfile.ly
> >
> >
> I don't understand why it has to be "eps", but it's the only way I found...
> do you have another option to get cropped images ?
>
> @David : I'm writing a program that generates html files including images
> with lilypond scores.
> My first attempt was using "lilypond-book" but I need more control (I want
> to include midi file for example).
> I will delete the remaining EPS file from my program.
My workflow is different, partly because I also use it with LaTeX files
that are unrelated to LilyPond. I work in PDF files because they are
easy to manipulate and include in other files without degradation.
They easier to archive, too, because they're multi-page.

I crop PDF files with   pdfcrop --margins 1   which assures at least
a one pixel border to each page. If I need to produce PNGs, I use
convert (imagemagick) like this, but with an appropriate
resolution/size:
$ convert -density 400 /tmp/fivecrop.pdf -alpha opaque -resize 50% /tmp/fivecrop.png
Convert automatically bursts PDF files into individual pages/images
as necessary.

(One detail regarding my previous post: my LaTeX script only
"trashes" .aux files when they consist of precisely '\relax \n',
which is an "empty" file.)

Cheers,
David.

five.pdf (35K) Download Attachment
fivecrop.pdf (34K) Download Attachment
fivecrop.png (61K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

Kevin Barry
In reply to this post by David Wright
> An example where I do have your problem is with pdflatex, which not
> only writes .aux and .log files, but leaves them world-writeable.
That's odd! Is it because of your umask?

Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

David Wright
On Tue 04 Feb 2020 at 20:38:47 (+0000), Kevin Barry wrote:
> > An example where I do have your problem is with pdflatex, which not
> > only writes .aux and .log files, but leaves them world-writeable.
> That's odd! Is it because of your umask?

No. (BTW it's the .aux and .pdf files, not the .log, and the LaTeX
variant is lualatex, successor to pdflatex.) Mine is
$ umask u=rwx,g=rx,o=

The earliest report I saw of the bug was back in 2010:

https://tug.org/pipermail/luatex/2010-September/001998.html

but more recent is:

https://bugs.launchpad.net/ubuntu/+source/texlive-base/+bug/1333016

though I'm using Debian stable, which usually means that bugs occur
later, or have already been fixed by the time stable is released.

My course of action is typically to write a workaround, and then
forget about it. All my scripts and functions call a bash function
-pdfl, which contains my fix. A single location also means I'm
prepared for when the flavour of choice changes from lua…tex
to something else (as happened with pdf…tex).

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: Lots of temporary files when generating png files

Anthony Rushforth
"-dcrop" is perfect in my case, thank you !

This flag is new and I didn't have it in the version I was using (stable).
For information it's documented here :
And the announcement is here :

Now I use the development version, and I can crop...

Thank you for sharing all the methods you use, I'll use them perhaps one day, probably using openCV instead.

Regards,
Anthony




Le mar. 4 févr. 2020 à 22:54, David Wright <[hidden email]> a écrit :
On Tue 04 Feb 2020 at 20:38:47 (+0000), Kevin Barry wrote:
> > An example where I do have your problem is with pdflatex, which not
> > only writes .aux and .log files, but leaves them world-writeable.
> That's odd! Is it because of your umask?

No. (BTW it's the .aux and .pdf files, not the .log, and the LaTeX
variant is lualatex, successor to pdflatex.) Mine is
$ umask u=rwx,g=rx,o=

The earliest report I saw of the bug was back in 2010:

https://tug.org/pipermail/luatex/2010-September/001998.html

but more recent is:

https://bugs.launchpad.net/ubuntu/+source/texlive-base/+bug/1333016

though I'm using Debian stable, which usually means that bugs occur
later, or have already been fixed by the time stable is released.

My course of action is typically to write a workaround, and then
forget about it. All my scripts and functions call a bash function
-pdfl, which contains my fix. A single location also means I'm
prepared for when the flavour of choice changes from lua…tex
to something else (as happened with pdf…tex).

Cheers,
David.