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

[dak]

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.

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