I have a static PDF Form created by Adobe Designer. In the properties of the text fields I can see the DataBinding value (the form is bound to an XML Schema).
I'm trying to read this information by means of Apache PDFbox 2.0 but I can get all the info but for this...
Have you any tip?
Thank you very much
Regards
Fabio
when you create a static PDF Form using the Adobe LiveCycle Designer there are two form definitions - the AcroForm and the XFA. The AcroForm has some of the form definitions of the design being done in the Designer but not all of them. The binding information unfortunately is not part of that. What you need to do is extract the XFA and get the binding from the XFA part.
Related
We're using mPDF, but when combining PDF files with Acrobat form fields, the output result strips the form fields.
I've combed through the documentation, looked extensively online, and I can't find a solution that works with mPDF.
mPDF uses FPDI in the back which simply does not support importing of form fields.
Update: As of mPDF 7 you can create fillable forms within PDFs dynamically - :D !
Are there any issues that can come up of removing the XFA format from a PDF form? I'm using PDFTK to fill form, and found that if forms are XFA, then PDFTK doesn't work unless I do a drop_xfa command first to create a new template form. One thing I did notice is that if I didn't do the drop_xfa, I could see the fields pre-filled on Acrobat Reader but not Acrobat Pro. Other views like Ubuntu Document Viewer, would be fine. I don't mind doing the drop_xfa but just checking is there might be issues with me doing that to forms that I am not aware of.
Example: If the form is filled, and it's to be read on a system to grab the fields/values to process.
Thank you in advance.
There are three types of forms in PDF:
Forms using AcroForm technology. In this case, each field corresponds with one or more widgets with fixed positions on specific pages. The form is described using nothing but PDF syntax.
Dynamic forms using the XML Forms Architecture (XFA). In this case, the PDF file is nothing but a container for an XML file that describes the whole form. We refer to this as dynamic XFA, because the form can expand or shrink based on the data that is added: a 1-page form can turn into a 100-page form by adding more data.
Hybrid forms that combine AcroForm and XFA technology. In this case, the form is described twice: once using PDF objects; once using XML. Obviously, such a form is not dynamic: the AcroForm part still defines widget annotations that are defined at absolute positions on specific pages. The form can't adapt to its data.
If you have a dynamic XFA form, dropping the XML will remove the complete form. There won't be anything left.
However, it seems that you are confronted with a hybrid form that consists of both AcroForm and XFA syntax. Hybrid forms are a pain because they often lead to confusion. For instance: a viewer that is not XFA aware, will show you the data as stored in the AcroForm. A viewer that is XFA aware, can give preference to the data as stored in the XFA form. What's the problem, you might ask? Aren't both forms equivalent?
Ideally, both versions of the form are indeed equivalent, but:
If the form isn't filled out correctly, the AcroForm can be different from the XFA form.
XFA has more functionality that AcroForm technology. For instance: a text field in an XFA form can be justified (similar to <p align="justify"> in HTML). However, this option doesn't exist in an AcroForm text field (you can only have left, center or right alignment). Hence if you have text that is justified in an XFA form, but you only look at the AcroForm, then the text won't be justified (because justified text doesn't exist in an AcroForm text field).
This is a long answer to explain that, if you have a hybrid form, it is in most cases OK to throw away the XFA part. You may have small differences, but if you are OK with what the form looks like in Ubuntu Document Viewer (a viewer that doesn't support XFA), then you should be fine.
DISCLAIMER: I am the CEO of the iText Group. Pdftk is a third party tool based on an obsolete and no longer supported version of iText. iText Group does not endorse the use of Pdftk.
Using iText api can I achieve the following?
We have a requirement of generating pdf documents with-
Header (static data) repeated in all pages. Same data should be filled or repeated in all pages.
Product Details section (grows data dynamically). This section is kind of table, but values are formed from multiple hibernate entity fields.
Footer repeats in all pages (hard-coded footer)
If this is achievable with iText api, we are planning to buy commercial licence.
With the core iText, you can fill out an XFA form by injecting XML. The functionality you describe requires that you create a dynamic XFA form first (e.g. using Adobe LiveCycle Designer). The result will be a filled out XFA form (XML wrapped in PDF).
If you want to flatten that dynamic PDF (for instance because you want to turn it into a PDF/A, PDF/UA, ordinary PDF document), you need XFA Worker. This will convert the XML stream to PDF syntax (no more XML inside the PDF, except for the XMP data, or, if you need to comply with the ZUGFeRD standard: an XML attachment).
iText is licensed under the AGPL, that means that you can use it for free under specific conditions. For instance: you may need to distribute all your own source code for free. XFA Worker is a closed source product, written on top of iText. You can download a trial version that will add "trial version" on top of all your flattened documents.
If you go for XFA, then your only options are Adobe LiveCycle ES or XFA Worker. I don't know of any other software that supports XFA flattening.
I am using Adobe life cycle designer to create docs in my application....I have all my documents in word and I use the export to option in Adobe Life cycle designer and i get the document converted and now I need to have a user fill in the exported document..so can some one please suggest me how this would go and we use the java script behind....
You could have them fill the form in Adobe land, then use the scripting method exportData to get the form data as XML, then inject that XML into your Word docx as a custom xml part.
From there, Word will use the XML in any content controls bound to it.
I have created a PDF file using Acrobat Adobe 8 that contains fillable fields.
Can that be programmed with ITextSharp instead of Adobe?
Note: I am not referring to filling out the PDF with ITextSharp, instead I would like to create the fillable fields on the PDF file using ITextSharp.
Any code would be appreciated.
thank you for your time!
You can create PDFs that contain fillable fields with iText[Sharp], but they won't look as nice as Adobe Acrobat, which is a much better design tool.
By fillable fields, I'm guessing you mean a TextField. Here's a link with some simple example code from the book to get you started. Specifically, take a look at the CreatePdf() and CellLayout() methods, and the iText API if you need more information.