Spaces:
Sleeping
Sleeping
| <html> | |
| <head> | |
| <title>html2ps/html2pdf interactive forms</title> | |
| <link rel="stylesheet" type="text/css" medial="all" title="Default" href="css/help.css"/> | |
| </head> | |
| <body> | |
| <h1>html2ps/pdf interactive forms</h1> | |
| <a href="index.html">Back to table of contents</a> | |
| <h2>Difference between forms in HTML and PDF</h2> | |
| <p>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. | |
| <h3>Field names are required</h3> | |
| <p>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 <strong>must</strong> 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. | |
| <h3>Field names should be unique</h3> | |
| <p>In HTML you usually <i>may</i> 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. | |
| </p> | |
| <h3>Form & field names</h3> | |
| <p>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 | |
| <pre class="code"> | |
| <form name>.<field name> | |
| </pre> | |
| (See also <em>PDF Reference 1.6 Fifth Edition, pp.638–639</em> | |
| for more precise and detailed explanation). When posting data in POST format, dots are converted to underscores, so you would get: | |
| <pre class="code"> | |
| <form name>_<field name> | |
| </pre> | |
| when processing the POSTed data. | |
| </p> | |
| <p>To illustrate what I've said above, consider the following example: | |
| <pre class="code"> | |
| <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> | |
| </pre> | |
| Usually you would get POST variables "item1" and "submit" when submitting the 1st form and | |
| "item2" and "submit" when submitting the 2nd form. When submitting the form from PDF, you'll get | |
| "form1_item1", "form1_submit" and "form2_item2", "form2_submit" correspondingly. | |
| </p> | |
| <p>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 <strong>highly</strong> 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.</p> | |
| <p>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: | |
| <ul> | |
| <li>Form names are unique throughout the page</li> | |
| <li>Field names are unique in the form</li> | |
| <li>Radio button values are unique inside the button group</li> | |
| </ul> | |
| </p> | |
| <h3>Button field values</h3> | |
| <p> | |
| 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 <strong>empty string</strong> as a value of this parameter. Thus, | |
| this check is a bad idea (bad, but rather popular): | |
| <pre class="code"> | |
| … | |
| if ($_POST['my_submit_button_name']) { | |
| … | |
| </pre> | |
| and should be replaced by this code: | |
| <pre class="code"> | |
| … | |
| if (isset($_POST['my_submit_button_name'])) { | |
| … | |
| </pre> | |
| </p> | |
| <h3>Image submit button click coordinates</h3> | |
| <p> | |
| 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! | |
| </p> | |
| <h3>Unsupported field types</h3> | |
| <p> | |
| "file;" and "hidden" fields are not supported. | |
| </p> | |
| <h2>Server-side form handling</h2> | |
| <strong>Note:</strong> there's an PHP extension designed to work with FDF files; you may wish to check documentation at | |
| PHP.net: <a title="Opens in new window" target="_blank" href="http://php.net/manual/en/ref.fdf.php">Forms Data Format Functions</a> | |
| <p>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: | |
| <pre class="code"> | |
| // 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); | |
| </pre> | |
| It just confirms the receiving of the posted data; "Thank you!" message will be shown as a popup by Acrobat Reader. | |
| Probably you would want to actually do something with POSTed data, but is it far beyound the area of this manual. | |
| <h2>Compatibility list</h2> | |
| <table> | |
| <thead> | |
| <tr class="odd"> | |
| <th>Element</th> | |
| <th>Is supported?</th> | |
| <th>Notes</th> | |
| </tr> | |
| </thead> | |
| <tbody> | |
| <tr class="even"> | |
| <td>Text field (<input type="text">)</td> | |
| <td class="yesno">Yes</td> | |
| <td></td> | |
| </tr> | |
| <tr class="odd"> | |
| <td>Password field (<input type="password">)</td> | |
| <td class="yesno">Yes</td> | |
| <td></td> | |
| </tr> | |
| <tr class="even"> | |
| <td>Submit button (<input type="submit">)</td> | |
| <td class="yesno">Yes</td> | |
| <td>Value of button "value" attribute is not posted</td> | |
| </tr> | |
| <tr class="odd"> | |
| <td>Reset button (<input type="reset">)</td> | |
| <td class="yesno">Yes</td> | |
| <td></td> | |
| </tr> | |
| <tr class="even"> | |
| <td>Plain button (<input type="button">)</td> | |
| <td class="yesno">Yes</td> | |
| <td>Renders and you may click on them, but there's no much use of buttons, as Javascript is NOT supported</td> | |
| </tr> | |
| <tr class="odd"> | |
| <td>Checkbox (<input type="checkbox">)</td> | |
| <td class="yesno">Yes</td> | |
| <td></td> | |
| </tr> | |
| <tr class="even"> | |
| <td>Radio (<input type="radio">)</td> | |
| <td class="yesno">Yes</td> | |
| <td></td> | |
| </tr> | |
| <tr class="odd"> | |
| <td>Textarea (<textarea>)</td> | |
| <td class="yesno">Yes</td> | |
| <td></td> | |
| </tr> | |
| <tr class="even"> | |
| <td>Select (<select>)</td> | |
| <td class="yesno">Yes</td> | |
| <td></td> | |
| </tr> | |
| <tr class="odd"> | |
| <td>Image (<input type="image">)</td> | |
| <td class="yesno">Yes</td> | |
| <td></td> | |
| </tr> | |
| <tr class="even"> | |
| <td>File (<input type="file">)</td> | |
| <td class="yesno">No</td> | |
| <td></td> | |
| </tr> | |
| <tr class="odd"> | |
| <td>Hidden (<input type="hidden">)</td> | |
| <td class="yesno">No</td> | |
| <td></td> | |
| </tr> | |
| </tbody> | |
| </table> | |
| </body> | |
| </html> | |