Converting Static XFA Forms to AcroForms using the Datalogics PDF Java Toolkit

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:
Well… I pretty much covered everything you’d want to know up above. That one line of code will remove the XFA dictionary leaving the AcroForm in place and allowing the PDF to be edited in Acrobat and filled and submitted consistently. You can stop with that one line but the Gist does go a little further in that it also removes the three JavaScripts that Designer injects to check that you have the right version of Acrobat for filling an XFA form. These are no longer necessary so we remove them by name.

Some Concerns:
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.  

Share this post with your friends

2 thoughts on “Converting Static XFA Forms to AcroForms using the Datalogics PDF Java Toolkit”

  1. I had an interactive form created for me. The form was created using LiveCycle Designer. Unfortunately, a few minor changes were needed to be made and when I made them using LiveCycle Designer, I am unsure how to properly save and convert the form back into PDF so that it can be properly used on mobile devices. The company that originally created the form explained to me that they convert the file to Acroform through a process involving the JavaScript. Could you explain to me how exactly I would use the DataLogistics Toolkit to do exactly what you discuss above?

    1. Hi Lucas,
      I passed your comment along to our Senior Product Manager, Vel Genov, and he recommends the following:
      “The PDF Java Toolkit is great when processing forms automatically, or implementing form capabilities in your application. For a one-off process, like the one you have, I’d suggest taking a look at Adobe Acrobat. It might be able to edit the form you have.”
      We hope this helps! If you have any other questions, feel free to contact us.

Leave a Comment

Your email address will not be published.

Get instant access to the latest PDF news, tips and tricks!

Do you want monthly updates on the latest document technology trends?

By submitting the form, you agree to receive marketing emails from Datalogics. You may unsubscribe at any time. 

Like what you're reading?

Get Datalogics blogs sent right to your inbox!

By submitting the form, you agree to receive marketing emails from Datalogics. You may unsubscribe at any time.