Question : Submitting fields from online (in browser) or offline (in Acrobat Reader) .pdf form to server for processing

Looks like there has already been a lot of discussion about his issue.

I found a few references:

http://www.nitropdf.com/help/submit_form_data.htm
http://koivi.com/fill-pdf-form-fields/

addressing what I'd like to do.  

Ideally, I would like to display a PDF form residing on the server inline in the users browser, have them submit the form via a button which I guess you can create with Adobe Acrobat Pro and you can specify what forms processor you want to submit to and what to pass with the submit.  Unfortuantely, there is an issue with displaying PDF forms inline in all browsers.

In IE, it works exactly as desired, you can submit the form as HTML form to a .php processor and the POST data is something like.

Array
(
    [Date_MonthDayYear] => 11-16-1957
    [Students_Name_Please_Print_Clearly] => John Doe
    [Button1] =>
)

Doesn't work in FF or Safari for me though as the PDF plug-ins don't work.  Safari display online with the Acrobat plug in, but the form submission feature doesn's work when pushing the submit button.  FF doesn't display online at all form me.

1.  Wondering if there is a work around for this somehow with the other browsers.

If you try to submit offline using Acrobat reader, the submit does send data to the server but I get a response saying:

Cannot process content of type text/html

presumably because the response is passed back to Acrobat Reader and it is expecting some different.  For it to work as desired it sound like you need to have the document loaded into the browser because the browser can more easily interpret the response.

Given that .pdf's are so prevalent, rather than having to reinvent an HTML or other form of them, it would be nice to be able to submit the forms online using the prefab .pdf.

The second article:

http://koivi.com/fill-pdf-form-fields/

describes something a little different which I don't quite understand.  I played around with it a little but it did something weird to my system (flickering screens with Safari, FireFox and Adobe Reader).  From what I gather it the FDF file contain the form data in an Adobe proprietary format:

e.g.

%FDF-1.2
%‚„œ”
1 0 obj
<<
/FDF << /Fields [ <</T(__NAME__)/V(test)>><</T(__TITLE__)/V()>><</T(__EMAIL__)/V()>><</T(__ADDRESS__)/V()>><</T(__CITY__)/V()>><</T(__STATE__)/V()>><</T(__ZIP__)/V()>><</T(__PHONE__)/V()>><</T(__FAX__)/V()>><</T(__CSZ__)/V(,)>>]
/F (http://pdf.form.server.loc/test.pdf) /ID [ <628c6497025b9549a0aa1cc1e45dc317>
] >>
>>
endobj
trailer
<<
/Root 1 0 R

>>
%%EOF

From what I gather, the fdf contains the submitted form data and fields and if you open that with the link to the form embedded in the PDF you get the populated form.  This isn't really what I'm interested since in that case they created an HTML form online without using the PDF as a template.  They simply collect the data and have a method to populate the form with the submitted form data.

Like I say, this seems to actually work in IE, you can submit the form to a processor, in my case PHP, and could presumably do some error checking, etc. (too bad you probably can't do this via AJAX?), but it doesn't work in other browsers because the don't have a functional plug-in for that.

I was hoping that there has been some progress or other approaches since this was last addressed.

Basic requirement is to display a PDF form to the user in their browser online, have them complete the form online and them submit the form, either as the complete PDF file with populated data, or with just the form data submitted, or preferably both the form as a completed document and the data to store in a database.

Thanks.

Answer : Submitting fields from online (in browser) or offline (in Acrobat Reader) .pdf form to server for processing

Hi, sscotti.  I'd like to help here, but I think you have already found the unfortunate answer: inconsistent browser support for a non-standard plug-in.  Couple of ideas that may be useful...

1. Try it in Opera.  If it works there, you might want to recommend that browser to your clients for this particular form.  Opera is very rigid about standards-compliant processing.  If it doesn't work there, you might want to look for another design for this application.  Not because Opera is so popular (it's not) but because any dependency on non-standard interfaces puts you at risk for future failure.  We call this a "brittle" design pattern, and it is to be avoided.

2. Forget about Safari.  Apple and Adobe seem to be having a spat over the use of Flash on the iPhone.  Apple is having none of it (a position I completely understand given the fact that Flash content has to be served from the internet, and internet data requires about 1,000x the battery power of data already stored in the phone).  Since Flash sites will deplete the batteries on iPhones, Apple does not want that, and Adobe is upset about it.  Net-net: Don't build your app in a way that requires two other companies to cooperate on advanced non-standardized browser plug-in features.

3. A possible solution might be to use a plain old HTML form to collect the data you need.  Submit that form to an action script to accomplish the validation.  Once validated, the action script can use FPDF to write the PDF file, and can present the finished PDF to the client.  Almost any browser can display a PDF correctly.  It may not sound sexy, but it lets you use JavaScript (if you like that sort of thing) as a client-side data inspector, and it doesn't depend on any arcane technologies.  The FPDF class is very flexible, fast and easily extensible.

HTH, ~Ray