another prepopulating ? - use php for web

There are a couple of basic strategies for server side form prepopulation.

1. Use an Adobe server or third party product to manipulate the form on the server and then, in the PHP response return a simple web page with the PDF on it (in an object tag). Appligent (www.appligent.com) makes a form filling tool called APMerge. On the free side, there's the iText Library.

2. This is the easy and cheap method. The server script uses the MySQL data to build a PDF Data file, one of the really well know ones (FDF, XFDF, or XDP). Make sure the original PDF file is specified in the data file. Then in the response to the client, pass this file back to the user with the proper mime type specified in the HTTP Response Header. The browser will recognize the MIME type, load Acrobat/Reader, acquire the PDF file path(URI) from the data file, load the PDF file, and then merge the data in to the PDf.

Hello Thomp,

Thanks so much for replying! Love the 'easy and cheap' method - I'll go w/ #2! I've been trying all day to get going with generating an FDF file (I didn't think that was an option from me from reading some of the product data, but after looking through here, I'm glad it is. I am using forge_fdf www.pdfhacks.com/forge_fdf/ to generate my FDF file - it looks OK...

When I try to serve it though, I get the old 'Open with' message box and then Acrobat can't read the FDF file saying that it can't open the FDF because it's not a supported filetype. I have saved my form under 'Distribute Form' in Acrobat Pro 8, assuming that the user rights/security would be OK (another post - http://www.acrobatusers.com/forums/aucbb/viewtopic.php?id=12784). Would I be sending the wrong mime type? In my header statement(s) I have tried the 2 I have seen in examples:

Content-type: application/vnd.fdf

Content-type: application/pdf'
Content-disposition: attachment; (+ filename)

Do users then have to have the Reader Extensions installed? Or do I have to have the FDF toolkit on my server? I used the forge_fdf (vs. the toolkit - http://www.acrobatusers.com/forums/aucbb/viewtopic.php?id=3816).

Any clarification would be greatly appreciated - thank you again for responding!

Obviously your FDF is not in the correct format or there is something very strange going on.

The FDF toolkit is really the best tool for creating correct FDF files and for parsing them. I believe there is a PHP version. But, just for a sanity check you need to make sure the mechanics of your setup are correct before playing around with creating FDFs. Here's what you do:

1. Copy a sample PDF to your server, the same one that the PHP script is on, and preferably the same folder.
2. From a client computer, Load the PDF from the server into the standalone Acrobat Pro, not into a browser.
3. In Acrobat, Select the "Forms-> Manage form data" menu item and save the data to FDF.
4. You should be able to copy this file to the server, Link to it from a browser, and have Acrobat load it. There is an example in the Acrobat SDK which will provides the HTML code for putting an FDF link on a web page. Normally you would link to another HTML page that has the FDF URI in an Object Tab.
5. Copy the text from the FDF file into your PHP script and return it verbatim from a web link to the script. Use "application/vnd.fdf" as the MIME type.

Make sure this works first. If this doesn't work then something is wrong. I've done it before many times, so I know it can work.

The user does not have to have Reader extensions and you do not need to use the FDF Toolkit. In fact, I only use toolkit for parsing FDF files and for adding horribly complex (and/or binary) things to the FDF. For normal data or script oriented FDFs I just put the text together, it's easier.

You can find lots more info on this in the Acrobat SDK, which you can download from here:
http://www.adobe.com/devnet/acrobat/

Hello Thomp -

Thanks - there was a problem w/ the FDF generation so I just wrote my own (I just need to specify a few fields). I didn't have the option to save my form data as FDF from Acrobat - (I have 8 Pro, don't know if maybe it is no longer an option).

So it is now working using the application/vnd.fdf and php generated fdf - thank you so much for your help!

I just have one remaining thing to do - and I know it's not directly related to the pdf generation.... but since I'm here and mostly likely the great people here have come across this - it's more browser related. My filled in pdf opens in a new window, but the old window just hangs. My web page has a button for the pdf generation, which directs to a .php where the fdf is generated and I do a:

header("content-type: application/vnd.fdf") ;
echo $fdf ;
exit ;

This is FF, it does the same in IE (opens the new window in FF, my default browser) and the 'old' window hangs.

I've tried a workaround I found for an IE bug (http://support.adobe.com/devsup/devsup.nsf/docs/52258.htm) which is having my php page just serve the html as:

... php fdf file gen ...
?>Which opens the pdf in the same window - but without the fdf data... Any pointers appreciated - I know it's offtopic. Thanks.

First, since you are using a LiveCycle form Acrobat doesn't display the FDF option. But you can still save out the data as FDF from this form. Run this line of code in the Console Window

this.exportAsFDF();

Hmm, I've had some wierdness with returning FDF directly to a browser, but nothing as bad as you've explained. Possiby this is because I've always done this for closed environments where the browsers and security are controlable. And yes, I know IE has all kinds of issues.

Really, the best way to get the FDF to load is to write the FDF to a file on the server and then generate an HTML page with an object tag in it, which is returned to the browser. The FDF is referenced in the object tag. There is an example of the exact syntax you'll need in the Acrobat SDK examples (link in the last post). This should get around all the browser issues since it is an explicit command to load the Acrobat viewer into the HTML, so you're not depending on the browser to know what to do with it. This should also help the issue of the original page hanging since you're making a clean break by opening an HTMl page in a new window, as opposed to a raw FDF.