About a month ago, Adobe announced that it would never support XFA forms in Adobe Reader on mobile platforms (see blogs.adobe.com on April 16, 2014). XFA forms are much more dynamic and interactive than ordinary PDF forms (AcroForms) and some mobile operating systems place restrictions on what can be done on a mobile device.
This makes it very difficult (impossible actually) to provide the same dynamic PDF experience you expect on the desktop across all mobile devices using PDF. As a result, Adobe Reader Mobile does not support XFA based PDF’s created in the LiveCycle Designer and it will not provide this support in the future.
But then how are we going to present these forms on mobile devices?
There are basically two options. Adobe and IDR Solutions offer the interactive solution, converting XFA to HTML 5 for consumptions on the mobile device. We offer the non-interactive solution, where we flatten the XFA form into an ordinary PDF document that can be viewed in any PDF viewer. The former solution is recommended when the form needs to be dynamic and when you need the form to respond to user input; the latter solution is recommended when you want to display, archive, secure the data in the form.
When you look at the changelogs of iText 5.5.1, you immediately see that we've invested in even more development of XFA Worker.
Now that XFA Worker creates Tagged PDF, our customers started experimenting with the generation of PDF/A and PDF/UA from XFA forms. This resulted in some extra enhancements and bug fixes. For instance: we discovered that we didn't fully support PDFs that comply with PDF/A as well as PDF/UA from XFA. This is now fixed.
Apart from further PDF/A enhancements, we introduced a conformance level that allows you to create documents that are in compliance with the ZUGFeRD standard (for instance: invoices). The ZUGFeRD standard is a superset of PDF/A-3 where you combine a human-readable PDF with a machine-readable XML attachment.
Talking about XML: We have also fixed a number of bugs in XML Worker. Some combinations of tags gave odd results, and there was a problem with tables and rowspans.
As we speak, the ISO committee for the PDF standards is meeting in South-Africa. One of the new standards that is being discussed involves XFDF. This new standard introduces much needed documentation for the Forms Data Format in general. We noticed that FDF is used quite frequently and we added some new functionality. Important: the input source is no longer closed automatically when using
FdfReader; you're responsible for closing that stream in your code.
Finally, we still find ways to improve RUPS. Not a day goes by without us using RUPS to look inside a PDF.