Re: Embed LilyPond source files inside generated PDF (issue 225040043 by address@hidden)

[v . villenave]

Here’s a slightly better-looking version (but the C++ part needs more
work once I figure out scoping and GC-related questions).


https://codereview.appspot.com/225040043/diff/40001/lily/sources.cc
File lily/sources.cc (right):

https://codereview.appspot.com/225040043/diff/40001/lily/sources.cc#newcode78
lily/sources.cc:78: source_file_list = scm_cons (ly_string2scm
(file_string), source_file_list);
On 2015/04/09 13:37:42, dak wrote:
> any reason you don't rely on the per-parser array source_files_ for
your
> list of source files?

Assuming you’re referring to the sourcefiles_ vector, that was my plan
initially. How can I access it outside its (Sources
constructor/destructor) scope so that I can convert it into a Scheme
list? Every attempt I made results in segfaulting.

> if I do lilypond
> -fembed-source-files a.ly b.ly
> the PDF for b.ly will include the source(s) for a.ly.

Hm, indeed. (And with more than two .ly files, Guile GC complains.) I
hoped the SCM_INIT_FUNC mechanism would prevent it, but it obviously
gets initialized only once.

> I might add that you forget to protect it from garbage collection,
likely inducing crashes

I couldn’t find an example of a protected global variable (protected: is
always used inside a class, and scm_gc_mark in engravers or iterators).
But I’ll be happy to learn more.

https://codereview.appspot.com/225040043/diff/40001/scm/backend-library.scm
File scm/backend-library.scm (right):

https://codereview.appspot.com/225040043/diff/40001/scm/backend-library.scm#newcode85
scm/backend-library.scm:85: "-P"
On 2015/04/09 13:37:42, dak wrote:
> This seems quite unrelated to the issue of this patch and the
rationale for
> specifying this option is totally undocumented.

The patch just doesn’t work without it. (Not does it work, as I said,
with older Ghostscript releases like 8.7 that we’re distributing with
GUB.)

From what I understand, -P makes Ghostscript look for external files
(not just libraries but also, as is the case here, embed-able files) in
the current directory (or using paths relatively to the current dir).
Which is the desired behavior here, since we want it to find the ly file
(as well as any \includ-ed source files).

https://codereview.appspot.com/225040043/diff/40001/scm/framework-ps.scm
File scm/framework-ps.scm (right):

https://codereview.appspot.com/225040043/diff/40001/scm/framework-ps.scm#newcode421
scm/framework-ps.scm:421: (map (lambda (fname)
On 2015/04/09 13:37:42, dak wrote:
> Use of `map' instead of `for-each'.

Done.

https://codereview.appspot.com/225040043/diff/40001/scm/framework-ps.scm#newcode422
scm/framework-ps.scm:422: (set! idx (1+ idx))
On 2015/04/09 13:37:42, dak wrote:
> seems cleaner to just give two list arguments to for-each,
> the second being (iota (length source-list)).

Done. That’s beautiful.

https://codereview.appspot.com/225040043/diff/40001/scm/framework-ps.scm#newcode425
scm/framework-ps.scm:425: [ /_objdef {ly~a_stream} /type /stream /OBJ
pdfmark
On 2015/04/09 13:37:42, dak wrote:
> [ ... pdfmark is a really ugly pairing.  I'd rather use mark ...
pdfmark

I’m not sure I can use anything else than pdfmark, since it appears to
be the official keyword in Adobe’s specification:
http://milan.kupcevic.net/ghostscript-ps-pdf/#marks

https://codereview.appspot.com/225040043/