Filling PDF Forms

[Bob Sneidar]

So instead of trying to piece together a demo stack of how I am filling PDF forms, I thought I would just write a (reasonable) short essay on how to. 

First of all, you will need Acrobat Pro, preferably something 9.0 or higher. This is because Acrobat Pro is capable of executing Actions, and my current method depends on this. I do not think Reader can. 

Next open any fillable PDF form (or create one if you like). I like to rename the form fields myself, because I have a mind that if they have the same name as columns in my database table, I will be able to automate this process more fully later. But for now, any field names will do. 

Next, put something… ANYTHING in each field, even a space. This is because Acrobat will not export a field in the FDF data file (which we will discuss later) unless there is something in the field. There IS a way to use Javascript to do this with empty fields, but I don’t want to go there yet. 

Once they are populated, choose Tools/Forms/More Form Options and select Export Data… the default is Acrobat FDF files. Save the FDF file in the same place as the PDF. (You can use a text file too, it may be easier to parse but I like to use these). This will become important later, because Acrobat will use the RELATIVE location of the FDF file when it goes to populate itself. (You can use a text file too, it may be easier to parse but I like to use these). 

Now in Livecode you can open the FDF file as a low level file (it’s a kind of XML style text file) and it will look something like this: (I’ve deleted most of the fields but you will get the idea)

%FDF-1.2
%‚„œ”
1 0 obj
<</FDF<</F(Color Defaults.pdf)/Fields[<</T(Signature)/V()>><</T(assetid1)/V()>><</T(assetid2)/V()>><</T(assetid3)/V()>><</T(assetid4)/V()>><</T(assetid5)/V()>>]/ID[<D16466192A84EA448A7B1E60C47B1B1F><A2E8445CAEAB454EB39D1697A21C88EB>]/UF(Color Defaults.pdf)>>/Type/Catalog>>
endobj
trailer
<</Root 1 0 R>>
%%EOF

Notice the field definitions start with “Fields” and a left bracket and end with a right bracket. Everything else is header and footer data, which by the way MUST remain intact, or Acrobat will not use the FDF file. Whatever you put inside the V() parts is what will later populate the PDF file. Now in your PDF File, choose Tools/Pages/Page Thumbnails. On the left you should see thumbnails of your form pages. Right click the first one and select Page Properties. Select the Actions tab, then select Page Open as the trigger, and Import Form Data as the action. You will be prompted for the FDF file you created. Confirm everything then save the PDF form. 

Now, from within Livecode, open that FDF we created earlier as a low level file and parse it out in such a way that you insert the values you want in the form in the proper places. Next time you open the form it will populate with the data you put in the FDF file. If you made any mistakes, Acrobat will fill fields up to the point there is an error, and go no further. Useful for troubleshooting. If you *REALLY* bunged up the FDF file, like the header and footer, it won’t work at all. 

Now in my app I get a little bit fancier. With Livecode I create a folder structure for the copier installs I am going to do, and then make COPIES of the PDF file and the FDF files (not yet filled in) in the proper locations. Because Acrobat uses the file path relative to the location of the PDF, it will find the copy of the FDF file and use that, not the original. 

I then query the database, and populate the copies of the FDF files, and then tell Acrobat to open the PDF's. Currently I use Applescript for this, but I believe there is a way to do this from a command prompt in Windows as well. I suspect any *nix OS has a way to do this. 

It looks really cool when I click the button and multiple forms start to open and fill themselves, but as you can see, it ain’t rocket science what I am doing here. Recently however, I stumbled across a means to have Applescript assemble a Javascript command and then send it to Acrobat. This would allow me to bypass the FDF data file method altogether, and modify the PDF directly. But rocket science THIS IS! There is an advantage to this method though that may make it all worthwhile. Suppose you make edits to form fields in the PDF that were first auto filled by the FDF import. You save and close the PDF, but later decide you need to open it again. Guess what? The FDF data OVERWRITES your edited PDF data! Not cool! 

So my next trick is to implement this new means of populating the PDF’s, but I am unsure how to work this out in Windows. 

Nuff for now, that is as short as I can make it. 

Bob