Using XFDF for pdf

Does anyone have experience using XFDF for pdf's? Are there any pitfalls in using this approach?

Step1 - I would need to create a pdf (adobe pro) with read only fields that are bound to elements in XML. This would act as a stencil to overly the data.

Step2 - Create custom classes that generate the XFDF XML string from data in our database.

Step3 - When a user requests a pdf, we simply would retrieve the data from the DB, construct the XFDF string and flush the string to the browser.

The main benefit to this architectural decision is that there is no need to store pdf's in the db or on hard drive. Additionally, I have seen many pdf generation implementations that u开发者_如何学Gose home grown batch processes that are buggy and only create another 'moving part' in an application.

---

I've been using XFDF for my projects and the technology proved to be reliable and sustainable. Firstly because it is XML, I could compress the XML and store them persistently with low foot-print. As Mark Storer has explained above, there are limitations that XFDF could not do that is support script. Should you require a library that does the XFDF/FDF field merge, you might give [nguyen][https://github.com/joneslee85/nguyen] gem a try.

---

I've written some XFDF, yes. Your approach sounds good.

You might want to consider FDF instead of XFDF. FDF can do things that XFDF cannot... You can add script (in "Before"F and "After" entry points), and alter field appearances. IIRC there are a couple other bells and whistles as well, but those are the ones I use.

The PDF forms we build have a LOT of script it them, and quite a bit of our initialization goes on within "After" (with a couple bits in "Before"). One of our none-too-standard field types require the ability to alter a field's appearance as well.

The potential issue with this sort of approach is Signature Fields. You must save the PDF to preserve the signature validity. You can work with this however... just save those PDFs and when someone requests that particular instance you point the [X]FDF at the signed form rather than the unsigned template.

FDF isn't any harder to write than XML. It uses PDF's syntax minus the need for an xref table and with a different root object/layout.

%FDF-1.2
1 0 obj 
  <</FDF 
    <</Fields [
      <</T(name1)/V(value1)>>
      << /T (name2) /V (value2) >>
      <</T(list1) /Opt [ [(display1)(value1)] [(display2)(value2)] ] /v(value2) >>
      ... 
      ]
      /F (pathOrURLtoForm.pdf)
      /JavaScript <<
        /Before (var foo = "blah";)
        /After(someFunc/(/);)
      >>
    >>
  >>
endobj
trailer
<</Root 1 0 R>>
%%EOF

There's some escaping to do in various places, but in general it's pretty simple. iText has an FDFWriter class that'll do most of the work for you, though I don't believe it supports all the bells and whistles FDF supports.