Given an existing PDF, iTextSharp can fill in the field values (AcroForm or XFA/LiveCycle forms).
HOWEVER, while iTextSharp (and iText) can handle any old AcroForm, it can only FLATTEN static liveCycle forms.
Also, a PDF form can submit itself in a number of ways:
- FDF: a dialect of PDF. Mostly name/value pairs, with some Extra Stuff around it.
- HTML-style
- PDF: PDFs can submit themselves (with form data) to a URL. You can just open & flatten, no need to worry about filling the form in a second time. I believe this is restricted to "Reader Enabled" forms in Reader.
iText's PdfStamper (in append mode!) can fill in field values without breaking a PDF's Reader-Enabled-ness.
Your workflow becomes:
- Fill in the reader-enabled form with iText's PdfStamper in append mode, and serve that PDF up to the user.
- Receive the filled PDF from the user
- Flatten the PDF with another PdfStamper. Simply "open, setFormFlattening(true), close()".
Rather than filling in the PDF, you can serve up FDF's with the field values and a reference to the PDF template (which again, to submit the full PDF IIRC requires Reader Enabling, from Acrobat). This is noticeably more efficient than parsing a PDF and serving it up every time.
An FDF looks something like this:
%FDF-1.2
%âãÏÓ
1 0 obj
<</F(http://www.mySite.com/myPDF.pdf)
/Fields[
<</T(Check1)/V/Off>>
<</T(Some Field)/V(A value)>>
<</T(AnotherFld)/V(1.0)>>
<</T(You get)/V(the idea)>>
]
>>/Type/Catalog>>
endobj
trailer
<</Root 1 0 R>>
%%EOF
<< and >> wrap "dictionaries" (name value pairs).
( and ) wrap strings
[ and ] wrap arrays
/ leads "names". Names are used for dictionary keys, and occasionally Other Stuff.
You have to escape some characters in names and strings:
String escapes start with a '\'. \r, \n, \t, \b, \f, (, ), and \. You can also escape any old character value IN OCTAL thusly: \ooo, where the 'o' are octal values.
Names escape Completely Differently (grr).
Name escapes start with a '#', followed by a two digit hex number. HEX this time, not octal. Grr grr. Anything not in a-z A-Z 0-9 . _ ; * @ should be escaped. You CAN escape everything, it's just horribly inefficient.
You may well need to worry about string escapes (for field values in particular, and possibly for your PDF path/URL), but you almost certainly won't need to worry about name escapes.
There are various libraries to write FDF for you, but I find it easier to just bang out FDFs with simple string concatenation.
Note that FDF supports quite a bit more than that, but many FDF libraries do not, so you must build them yourself if you go off the beaten path.
