Sample of the Week:
I recently heard from a customer who was having trouble getting consistent behavior from a PDF Form. In some PDF viewers, in Adobe Acrobat, the form worked perfectly if a user filled the form with something else, their server couldn’t handle the data some of the time. It ends up that the form was created in LiveCycle Designer and even though the customer saved it as an “Adobe Static PDF Form”, it was still an XFA form… a “Static XFA”.
To those of us familiar with LC Designer, this was obvious… but to people who just need to process forms and don’t have the tools to examine the guts of the PDF, the difference between an AcroForm and a Static XFA can be troublesome… especially since a Static XFA is 100% an AcroForm with just a bit of XFA mixed in. Yes – I know that’s a gross oversimplification so please feel free to add your own explanation as a comment.
Fortunately, this means that just about any PDF viewer that can fill an AcroForm can fill a Static XFA. Unfortunately, not all viewers are “XFA aware” and your form may get mangled by them.
- Microsoft’s Reader will allow users to fill a Static XFA form and modify the XFA dataset to match the AcroForm.
- PDF Expert on iOS will let you fill in the form but won’t update the XFA dataset.
- Preview on the Mac will simply delete the XFA dictionary altogether. So if your server is expecting to pull the XML dataset out of the filled PDF, you can’t always guarantee that the data will be there.
- Adobe Acrobat DC on mobile won’t let you fill the form at all.
So, for better or worse, the best way to guarantee as consistent an experience as possible for the end user and have the data stored in a way that the server can access it consistently, the best option is to use an AcroForm. Unfortunately, Acrobat doesn’t let you convert a Static XFA to AcroForm and LiveCycle Designer won’t let you save the file as an AcroForm.
So you’re out of luck?
The Datalogics PDF Java Toolkit makes it pretty easy. In fact, a single line of code will do the trick.
What You Need to Know First:
When you use LiveCycle Designer to create your form and save it as a Static XFA, it creates a regular AcroForm but adds an XFA dictionary to it that sits on top of the AcroForm. Essentially a PDF Background and an XFA foreground. There’s a really great explanation of exactly what a Static XFA or XFA Foreground (XFAF) is on Wikipedia here.
When users fill the form using an Adobe viewer, Acrobat and Reader make sure that the XFA data and the AcroForm data and appearances are synchronized. Other viewers may not… in fact, most don’t but the only reason the other viewers can do anything at all with the form is because of that, fully functional, AcroForm dictionary.
Additionally, the only reason that Acrobat won’t let you edit the AcroForm and forces you to use Designer is the existence of that XFA dictionary… remove the XFA dictionary and you’re left with just the AcroForm… the field names are a bit odd but they’re functional.
Back to the Code:
I’ll preemptively answer a few questions…
- Yes – any scripting that was added to the form in Designer is now broken… but it wasn’t going to run properly in the non-Adobe viewers anyway. You’re better off without it.
- Yes – the AcroForm very likely has the latest data if the form was already filled in. The Adobe tools keep the XFA and the AcroForm synchronized and the other tools just update the AcroForm data. You’re safe but should probably test my assumptions here.
- No – This won’t work for Dynamic XFA. With Dynamic XFA, the underlying PDF file is created dynamically… on the fly… by Acrobat. Removing the XFA Dictionary from the PDF isn’t helpful in that situation.
To get started with converting your Static XFA forms, download this Gist and request an evaluation copy of The Datalogics PDF Java Toolkit.