merging XFDF with PDF form to create final PDF server-side?

Question

This is what I have currently:

• User submits form data and gets a "download PDF" link.

• The link points to script which generates an XFDF file on the fly and outputs the XFDF file after setting the appropriate headers, etc.

• The XFDF file points to a password-protected PDF, which is the generic PDF form that uses the XFDF data to fill in the fields.

What I would like:

• User clicks the "download PDF" link.

• XFDF is generated on the fly (no file written to server).

• PDF and XFDF are merged server-side using generic PDF. Contents of final PDF are output to user same as XFDF was originally.

• Neither the XFDF nor the final PDF are ever saved to server.

I was looking at pdftk, which has a few options for dealing with FDF/XFDF files, but all of which assume that a) the original XFDF file exists as a file on the server and b) that the resulting PDF should be output as a file on the server.

Also, pdftk is 4 years old.

I was wondering if:

a) there was a newer equivalent to pdftk out there?

b) if there was a way, using a newer pdftk-like tool or using pdftk, to use dynamic paths so that the data never has to exist in file form on the server?

I recently learned about the built-in input/output streams using php:// but I'm still really fuzzy on how to use it, but maybe this would be a good place for this?

Answer 1

There are commercial applications that do that (you can find some at pdfstore.com), but with some programming, you can create your own using the same library that pdftk is using to process PDF files: iText (http://itextpdf.com/) There is also a .NET version - iTextSharp.

By doing that, you can access your data from your Java or .NET program, and it never needs to exist in file form, you could get it out of the database directly.

You can also recompile pdftk with a newer version of iText - that way, you can the latest PDF processing capabilities and the ease of use that you have with pdftk. You would still need a XFDF file however.