lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use GhostScript API instead of forking (issue 548030043 by address@h


From: jonas . hahnfeld
Subject: Re: Use GhostScript API instead of forking (issue 548030043 by address@hidden)
Date: Fri, 01 May 2020 04:44:05 -0700

On 2020/05/01 11:41:13, dak wrote:
> On 2020/05/01 11:18:11, hahnjo wrote:
> >
https://codereview.appspot.com/548030043/diff/583830043/lily/general-scheme.cc
> > File lily/general-scheme.cc (right):
> > 
> >
>
https://codereview.appspot.com/548030043/diff/583830043/lily/general-scheme.cc#newcode783
> > lily/general-scheme.cc:783: command += "(" + ly_scm2string (input) +
") run";
> > On 2020/05/01 06:42:43, hanwenn wrote:
> > > This doesn't hook very deeply into GS internals or how we arrange
the page.
> > > Could we get the same speedup by putting the batching into an
encompassing
> .ps
> > > file, and calling GS on that file once?
> > 
> > I think this would require substantial refactoring of how LilyPond
works. As
> far
> > as I understand, currently each input file is handled separately and
temporary
> > files are deleted after processing. To get similar speedup, we have
to reuse
> the
> > interpreter for the complete run of LilyPond.
> > 
> > > Also: is there a GPL'd version of Ghostscript for which this
works?
> > 
> > GPL Ghostscript 9.06 from 2012 is apparently the last GPL version.
You
> probably
> > don't want to stick with dependencies of that age ;-)
> 
> It would need to be GPLv3+ anyway.  Haven't checked, though.
> 
> preview-latex <https://www.gnu.org/software/auctex/preview-latex.html>
works by
> feeding scraps of PostScript control through stdin.  The main thing is
that
> startup and font loading are not once per graphics but per document. 
I have
> little enough clue how this would work for us, but obviously any way
of using a
> single Ghostscript session for multiple snippet conversions, including
just a
> large batch of input files generating lots of small output files with
a
> predictable naming scheme (this is what LaTeX/Ghostscript under
control of
> preview.sty can do) will get us significant benefits.  The Ghostscript
API is
> just one way of organising this.

Sure, we could also open an "interactive" gs command and keep it around
for the process. I didn't consider this different from using the API,
but if the license is happy as long as it's a separate process...

https://codereview.appspot.com/548030043/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]