Reported by Samuel Da Mota on Lilypond user here:

http://lists.gnu.org/archive/html/lilypond-user/2012-07/msg00105.html

Hi,

I'm a pretty much new user of lilypond and I have an idea for a almost dummy new feature: automatically attach lilypond code in pdf. With pdf files it is possible to attach a file into it. I think it would be nice to have a lilypond option that attaches the .ly files into the pdf. This way when someone creates a partition and upload it to a website, the code will be uploaded too, thus making it much more easier for any user to possibly modify it. Moreover it will help spreading the use of lilypond.

In linux it is easy to do it using pdftk (the command is "pdftk input_file.pdf attach_files source_file.ly output output_file.pdf"). It may be interesting to automatically call this command just after the pdf generation. Pdftk seems to be also available under windows and mac os.

Moreover, if this feature is accepted, it may be interesting to modify the default tagline which says "engraved by lilypond version x.y.z" to "engraved by lilypond version x.y.z with source file attached" to increase its visibility.

Of course, for musicians who doesn't want to share their lilypond code, this feature should be kept as an option (maybe turned on by default).

Best Regards,

Samuel DA MOTA

According to the following discussion, you can use the /pdfmark postscript command to attach files: http://forums.adobe.com/message/4438533

A sample eps file (hand-written text file) is attached, to create the pdf, you need to run ghostscript with the -dNOSAFER option to allow file access: ps2pdf -dNOSAFER test.eps

The resulting pdf file correctly shows the attachment in acroread. However, neither okular nor evince are able to detect the attachment, only acroread does.

More information about the file attachment subtype of the pdfmark command can also be found on page 488 of http://www.dpunkt.de/leseproben/1360/Kapitel_11.pdf

Here’s a patch that more or less implements that feature (although it doesn’t create a compressed archive when there are multiple files).

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

Passes make, make check and a full make doc.

reg test shows up

--snip--

input/regression/option-help.log

@@ -34,6 +34,7 @@ dump-profile (#t) Dump memory and time information for each file. dump-signatures (#t) Dump output signatures of each system. Used for regression testing. + embed-source-code (#f) Embed the source files inside the generated PDF document. eps-box-padding (3.0) Pad left edge of the output EPS bounding box by given amount (in mm). gs-load-fonts (#f) Load fonts via Ghostscript.

--snip--

James

Patch on countdown for April 9th

(Syntax consistency nitpick)

http://codereview.appspot.com/225040043

Patchy the autobot says: passes tests. Includes a full make doc

Patch on countdown for April 12th

Some improvements (but problems still exist)

http://codereview.appspot.com/225040043

Use mark _ pdfmark instead of [ __ pdfmark

http://codereview.appspot.com/225040043

Patchy the autobot says: passes tests. Includes a full make doc

Retrieve source file paths directly from Includable-lexer:: class

http://codereview.appspot.com/225040043

Patchy the autobot says: passes tests. Includes a full make doc

The current patch is broken, but it’s sorta by design (see my last comment on Rietveld).

I'll take a look eventually but right now I'm half through the alphabet on that other patch...

Patch on countdown for April 18th

I'm going to leave this on 'countdown' for April 21 as it seems there is still some discussion here.

Nothing has moved on - leaving on another countdown for April 24th - if I still see no change, I'll put this back to review.

Oh, it’s definitely on review, since it just isn’t working at the moment (ever since David made me add a "parser" arg that I’m not sure how to retrieve, cf the FIXME line #420 in framework-ps.scm).

For now, setting -dembed-source-code will make Lily crash, which is not ideal.

And while we’re at it, I’m not sure how to add a regtest for this feature: ideally we’d need something that checks the created PDF for an embedded file, extracts it and compares it to the source file (they should be identical).

Sorry, I am currently quite immersed in issue 1375 or probably rather a precursor of it (issue 4351 is already a bit of lead-up work). I'll get back to this one once I can find sufficient focus.

Leaving on review for now

David, do you still want me to leave this on Review?

As far as I can tell from Valentin's own comments, this does not currently work properly and my attention is required. So I'm afraid that it will need to stay on review right now. Sorry for that. I'm making progress on the stuff currently occupying my mind though, so I hope I'll be able to get to this here this week.

Keeping on Review

Keeping on Review still

Still keeping on review until I hear different from David K - as he asked for time in comment #23 and I don't see anyone clamouring for this patch to be pushed

Still keeping on review until I hear different from David K - as he asked for time in comment #23 and I don't see anyone clamouring for this patch to be pushed

Still keeping on review until I hear different from David K - as he asked for time in comment #23 and I don't see anyone clamouring for this patch to be pushed

Do I still keep on review or move to 'waiting'? Although I forget why people wanted me to keep the 'waiting' patches listed - but that's not important.

Currently "waiting". I've started taking a look but, uh, it is quite more tricky than I tried selling to Valentin.

And we don't want to expose absolute paths in the attachments while they might be required for actually getting the files.

Valentin?

The parser can now be retrieved in Scheme as (parser) and in C++ as

scm_fluid_ref (ly_lily_module_constant ("%parser"))

at the point of use (don't try storing it somewhere).

This involved several issues, most notably issue 4422. Hopefully this is the missing piece of the puzzle.

Yep; this should make things easier indeed. I’ll have a look, thanks for the ping!