html2ps/pdf interactive forms

Difference between forms in HTML and PDF

I guess, if you use html2ps script, then you know how forms are defined in HTML and how form data is sent using the POST format. This script tries to emulate the browser behavior as closely as possible; nevertheless, there's several important differences.

Field names are required

In HMTL, you may write an INPUT tag without "name" attribute and get working interactive control; often, submit and reset buttons are written this way. When using html2ps interactive forms, you must provide "name" attribute for all controls which should be rendered interactive. If you don't do it, the control will be rendered as a graphic like "Interactive forms" options disabled.

Field names should be unique

In HTML you usually may enter several controls with the same name into the same form and get some kind of results. PDF files do not allow such fields at all. In this case, all subsequent fields sharing the same name will be rendered as non-interactive.

Form & field names

Unlike HTML, the parameter names in POST request are not the field names. Acrobat Reader uses a "fully qualified field names" instead. It means that field is identified by composite string having the form

<form name>.<field name>

<form name>_<field name>

To illustrate what I've said above, consider the following example:

<form name="form1">
<input type="text" name="item1" value="test"/>
<input type="submit" name="submit" value="Submit 1st form"/>
</form>

<form name="form2">
<input type="text" name="item2" value="test"/>
<input type="submit" name="submit" value="Submit 2nd form"/>
</form>

The name of the form is taken from "name" or "id" FORM tag attributes (note that if both attributes are specified, then "name" have the higher priority). If both these attributes are missing, then the script attemts to generate an unique name for the form; Newertheless, it is highly recommended to add "id" or "name" attributes for every form definition. The autogenerated form names may suddenly change when you change the page content. It is not guaranteed that future html2ps versions will use the same name generation rules.

Also, you must note that html2ps is less tolerant to the form definition than most browsers. You may get conversion errors or even unpredictable results when viewing generated PDF if the following conditions are not satisfied:

• Form names are unique throughout the page
• Field names are unique in the form
• Radio button values are unique inside the button group

Button field values

In HTML, when you click on the Submit button, the posted data will include the value of "value" attribute for the button. When you're submitting form from generated PDF, you'll get an empty string as a value of this parameter. Thus, this check is a bad idea (bad, but rather popular):

…
if ($_POST['my_submit_button_name']) { 
…

…
if (isset($_POST['my_submit_button_name'])) { 
…

Image submit button click coordinates

In HTML forms, you'll get three POST varaibles after clicking on "image" submit button: <button>, <button>_x and <button>_y. When you're posting data from PDF you'll get only two last parameters!

Unsupported field types

"file;" and "hidden" fields are not supported.

Server-side form handling

Basically, you must use the script which accepts data in HTTP POST format and outputs result in FDF format. (Actually, in any format, but be prepared to Acrobat Reader complaints like "Cannot handle Content-Type: …") The minimal data-handling example is:

// output an empty FPF file

$outfdf  = fdf_create();
$tmpname = tempnam('../temp',"FDF_");
fdf_set_status($outfdf, "Thank you!");
fdf_save($outfdf, $tmpname);
fdf_close($outfdf);

fdf_header();
$fp = fopen($tmpname, "r");
fpassthru($fp);
unlink($tmpname);

Compatibility list