Populate form-fillable pdf from command line
Bob Babcock
line script and save the result (still fillable). The idea is to fill in
read-only fields such as a username, then have end users fill in other
fields and email back the forms. Most end users will have Acrobat
Standard, but some will only have Reader.
I made a test form with Acrobat 7.08 Pro form designer and I'm trying to
use pdftk 1.41 to fill the fields. The only way I've gotten this to work
is to use the pdftk drop_xfa option. But doing this removes features I'd
like to keep in the form such as formatting and adding up values in some of
the fields.
Is there a way to do this (under Windows) with pdftk or another tool? I
know pdftk is based on iText; would iText work better? We've got Acrobat 8
on order, will it make this task any easier? For that matter, would
dropping back to Acrobat 6 help? The pdftk documentation says xfa data
comes from Acrobat 7.
Thanks for any suggestions.
Paulo Soares
iText version that didn't yet support it. You can create the form in
Acrobat (not Designer) and have pdftk to fill it.
Paulo
Aandi Inston
>I made a test form with Acrobat 7.08 Pro form designer and I'm trying to
>use pdftk 1.41 to fill the fields. The only way I've gotten this to work
>is to use the pdftk drop_xfa option. But doing this removes features I'd
>like to keep in the form such as formatting and adding up values in some of
>the fields.
Designer is a powerful tool, but the choice of third party tools for
working with Designer forms (XFA forms) is very limited, if there are
any at all. You may find you have to work with Adobe products like
LiveCycle Forms (the name of a specific product).
From your description, and the suggestion of dropping back to Acrobat
6, it doesn't seem that Designer is a critical part of your workflow,
so I suggest using Acrobat forms instead.
----------------------------------------
Aandi Inston
Please support usenet! Post replies and follow-ups, don't e-mail them.
ReFOB
already. That is a flat textfile in a specific form, which keeps the
fieldvalues and can start a PDF to prefill with what ever you want.
So you can sent out the PDF and Start.fdf and ask your user to click on
the Start.fdf in order to open the pdf prefilled.
HTH, Reinhard
Aandi Inston
>If I understand right what you want to do, then a FDF file should do it
>already.
FDF files do not work with XFA forms either...
ReFOB
Aandi Inston schrieb:
>
> FDF files do not work with XFA forms either...
> ----------------------------------------
Good to know. Does that also mean that a FDF with JS-Code to fill the
fields don't work?
br, Reinhard
Aandi Inston
FDF files don't work at all. Also, XFA forms use a different set of
JavaScript classes: code is certainly not portable from Acrobat forms
to XFA forms, even if you could get it run that way.
Bill Segraves
Bob Babcock wrote:
> I'd like to make a form-fillable pdf, fill in some fields with a command-
> line script and save the result (still fillable). The idea is to fill in
> read-only fields such as a username, then have end users fill in other
> fields and email back the forms. Most end users will have Acrobat
> Standard, but some will only have Reader.
>
Users with Reader won't have a way to save a filled form to allow them
to email the filled form back to you. OTOH, you could add a submit
action, e.g., submit as HTML (URL-encoded name=value pairs) to your
form. The submit action should send the form data to a server-side
script that converts the submitted form data into the format(s) you
wish to support, e.g., FDF, XFDF, and then return the formatted form
data to the client-side browser to allow the user to save the form data
for future use.
> I made a test form with Acrobat 7.08 Pro form designer and I'm trying to
> use pdftk 1.41 to fill the fields. The only way I've gotten this to work
> is to use the pdftk drop_xfa option. But doing this removes features I'd
> like to keep in the form such as formatting and adding up values in some of
> the fields.
>
Pdftk is based on iText. Why not use iText to do what you wish to do on
the server side of the transaction, e.g., partially fill, but not
flatten the form, and then serve the partially-filled form to the
client-side browser?
> Is there a way to do this (under Windows) with pdftk or another tool?
Yes and no. AFAIK, there is no way for you to be able to provide
capabilities with the latest version of Reader that were formerly
provided with earlier versions of Reader. e.g., Reader 7 does not
appear to support "Import FDF" as an action, requiring the use of a
work-around, such as launching the form with FDF file.
That said, IMO, you'll have greater flexibility in the creation of the
PDF forms you need if you use iText to modify your existing PDF forms,
rather than using the capabilities offered by Acrobat.
> I know pdftk is based on iText; would iText work better?
Yes, IMO. You'd certainly have greater capability to modify your PDF
forms to suit your purpose. Keep in mind that iText is a developer
tool, while Pdftk is an end-user tool.
> We've got Acrobat 8
> on order, will it make this task any easier?
Easier for whom? Adobe wants your users to buy the full distribution of
Acrobat, rather than just using Reader. Please let us know what you've
found when you've tried Acrobat 8.
> For that matter, would
> dropping back to Acrobat 6 help?
It might, especially if you're going to use iText as a development
tool.
> The pdftk documentation says xfa data
> comes from Acrobat 7.
>
IIRC, the one submit action format that is common to all versions of
Acrobat forms is Submit As HTML (URL-encoded name=value pairs). If you
submit in this format, you can convert to any format you wish to
support with a server-side script. See the examples at
http://segraves.tripod.com/index4.htm, where you'll find one example
that has a page with several submit actions (FDF, HTML, XFDF), none of
which is supported by all versions of Acrobat or Reader. You'll see
that I use a server-side script to produce XFDF from an HTML submittal.
If you can provide a link to a PDF form that typifies what you are
trying to achieve, we might be able to help you better.
Cheers,
Bill Segraves
PDFrank
> "ReFOB" <Re...@web.de> wrote:
>
>
>>If I understand right what you want to do, then a FDF file should do it
>>already.
>
>
> FDF files do not work with XFA forms either...
I didn't know that!
To me, export to and import from FDF is one of the most attractive
features of Acroforms.
Bob Babcock
news:1166120009.0...@79g2000cws.googlegroups.com:
> That said, IMO, you'll have greater flexibility in the creation of the
> PDF forms you need if you use iText to modify your existing PDF forms,
> rather than using the capabilities offered by Acrobat.
Thanks to all who responded. It sounds like iText is probably my best
option, even though I've never done any Java programming before. I
installed the Sun Java development kit today and got hello world to run
before I ran out of time. I also found example iText code for setting form
fields. It looks like getting the Java development environment setup may
be harder than writing the code.
Bruno Lowagie
> It looks like getting the Java development environment setup may
> be harder than writing the code.
There's also the .NET port iTextSharp if you're more familiar with C#.
br,
Bruno
Bob Babcock
news:4582ca09$0$1128$ba62...@news.skynet.be:
Thanks, I saw iTextSharp but I haven't touched C# either. Anyway, I got my
Java build environment working. The trick was to do it at home where I
could work without interruption. I modified some sample iText code to fill
my test form. It's a simple enough problem that I did't need to know much
Java to modify a working example. Now I just need to look at the form
design and figure out why submit by email skips some of the fields. (I'm
on vacation today and have only Acrobat Reader at home, so next week...)
Bob Babcock
Acrobat form designer 7. With a Java program using iText I successfully
populate some read-only fields. But if I try to append my form to another
pdf, using code similar to concatenate.java or concatenateforms.java from
the iText Tutorial, the submit by email button breaks, fields formatted as
currency become unformatted and a field that's supposed to add up user-
entered amounts breaks. The form does remain fillable. Is this supposed
to work? Thanks.
Bill Segraves
news:Xns989BA8138E8...@208.49.80.252...
See Chapter 3, p. 78, in the book, "For the moment, iText doesn’t fully
support forms created with Adobe LiveCycle Designer; ..."
If you can provide a link to an example of the PDF form with which you are
having trouble, as well as an example of the iText code that generates it,
you might be able to get some help from iText users.
That said (written), a better forum for your question, IMO, would be the
iText mailing list (See link on www.lowagie.co/iText/).
Cheers,
--
Bill Segraves
Bill Segraves
news:bSZgh.273$w91...@newsread1.news.pas.earthlink.net...
> "Bob Babcock" <wss...@nospam.gis.net> wrote in message
> news:Xns989BA8138E8...@208.49.80.252...
> > Hopefully my last question in this thread: I'm using a test form made
with
> > Acrobat form designer 7. With a Java program using iText I successfully
> > populate some read-only fields. But if I try to append my form to
another
> > pdf, using code similar to concatenate.java or concatenateforms.java
from
> > the iText Tutorial, the submit by email button breaks, fields formatted
as
> > currency become unformatted and a field that's supposed to add up user-
> > entered amounts breaks. The form does remain fillable. Is this
supposed
> > to work? Thanks.
>
> See Chapter 3, p. 78, in the book, "For the moment, iText doesn’t fully
> support forms created with Adobe LiveCycle Designer; ..."
See also, Section 2.2.7, Concatenating forms with PdfCopyFields, pp. 66-67,
in the book.
Cheers,
--
Bill Segraves
Bob Babcock
> See Chapter 3, p. 78, in the book, "For the moment, iText doesn’t
> fully support forms created with Adobe LiveCycle Designer; ..."
>
> If you can provide a link to an example of the PDF form with which you
> are having trouble, as well as an example of the iText code that
> generates it, you might be able to get some help from iText users.
>
> That said (written), a better forum for your question, IMO, would be
> the iText mailing list (See link on www.lowagie.co/iText/).
Thanks. I just subscribed to the mailing list. Monday I'll check with the
people who will actually be using the form to get a decision on whether
concatenating it on the end of another pdf is even necessary. We've talked
about doing it either way. And I need to get my department to buy the
book...
Bruno Lowagie
> Thanks. I just subscribed to the mailing list. Monday I'll check with the
> people who will actually be using the form to get a decision on whether
> concatenating it on the end of another pdf is even necessary. We've talked
> about doing it either way. And I need to get my department to buy the
> book...
Note that the book doesn't talk about XFA.
It says that filling static XFA forms is supported,
but that's all. The manuscript was already finished
and reviewed when XFA support was added. I only
managed to add the information that was already
given to you by Bill.
The suggestion to use PdfCopyFields is a good one,
but it only works with AcroForms (created with
Acrobat, not Designer).
Of course I'm not saying the book isn't interesting.
It contains a lot of useful examples and ready-made
solutions.
And if you can wait till next week, we'll probably
implement the PDF1.7 feature called 'PDF packages'
where you can attach several PDFs so that they can
be viewed in Adobe Reader 8 as a package of files.
best regards,
Bruno
Bob Babcock
> And if you can wait till next week, we'll probably
> implement the PDF1.7 feature called 'PDF packages'
> where you can attach several PDFs so that they can
> be viewed in Adobe Reader 8 as a package of files.
> best regards,
> Bruno
I subscribed to the mailing list and the very first postings I saw were
about this. Sounds like packages might be just what we need. I suspect
you'll get your package support done before we get the messed up paperwork
for our Acrobat 8 upgrade straightened out. (We managed to time an order
for Acrobat 6 plus maintenance right so that we got 7 and now 8 for free.
But there's some confusion with license counts for Pro versus Standard that
is being worked on.) Thanks.
Bruno Lowagie
> I subscribed to the mailing list and the very first postings I saw were
> about this. Sounds like packages might be just what we need. I suspect
> you'll get your package support done before we get the messed up paperwork
> for our Acrobat 8 upgrade straightened out.
Yes, iText 1.4.8 has just been released.
I have added an example explaining how to make a PDF package here:
http://itext.ugent.be/itext-in-action/chapter.php?chapter=3#bonus
The example is really simple:
http://itext.ugent.be/itext-in-action/examples/chapterX/HelloWorldPackage.java
If you want to know what a PDF packages looks like, see
http://itext.ugent.be/itext-in-action/examples/chapterX/results/HelloWorldPackage.pdf
If you open the file in Adobe Reader 7, you'll get a warning
that the PDF version is higher than the one supported. The PDF
will open correctly and you'll see 1 PDF with 2 PDF files in
attachment. If you open the file in Adobe Reader 8, you'll see
the PDF Package 'in Action'.
best regards,
Bruno
Bob Babcock
news:em8nan$hos$1...@gaudi2.UGent.be:
> Yes, iText 1.4.8 has just been released.
>
> I have added an example explaining how to make a PDF package here:
> http://itext.ugent.be/itext-in-action/chapter.php?chapter=3#bonus
Thanks. I downloaded 1.4.8 earlier today and just now grabbed the new
examples.
Bob Babcock
> If you open the file in Adobe Reader 7, you'll get a
> warning that the PDF version is higher than the one supported. The PDF
> will open correctly and you'll see 1 PDF with 2 PDF files in
> attachment. If you open the file in Adobe Reader 8, you'll see
> the PDF Package 'in Action'.
The iText example works fine. I can include a fillable form in the package
and it retains all of its features.
But Adobe Reader 8 does something nasty: if I fill in some fields in the
form and then switch to one of the other pdfs in the package, the form data
I've entered is lost when I return to the form. As far as I can tell, this
is a Reader problem, not an iText problem. Reader 8 doesn't even warn
I'm going to lose data (7.08 does) if I close a simple fillable form.
With Reader 7.08, switching between the attachments is less convenient, but
you can do it without losing form data. (Looking at 8 again, I see I can
right-click on one of the pdfs and pick open in a new window. Then it
behaves like version 7.)
Bruno Lowagie
> The iText example works fine. I can include a fillable form in the package
> and it retains all of its features.
>
> But Adobe Reader 8 does something nasty: if I fill in some fields in the
> form and then switch to one of the other pdfs in the package, the form data
> I've entered is lost when I return to the form. As far as I can tell, this
> is a Reader problem, not an iText problem. Reader 8 doesn't even warn
> I'm going to lose data (7.08 does) if I close a simple fillable form.
I'm posting this to the iText mailing list.
We've got a Technical Evangelist from Adobe listening there ;-)
> With Reader 7.08, switching between the attachments is less convenient, but
> you can do it without losing form data. (Looking at 8 again, I see I can
> right-click on one of the pdfs and pick open in a new window. Then it
> behaves like version 7.)
I'll read the PDF Reference 1.7 soon; if there's a possibility
to fix the problem, I'll let you know.
A workaround could be not to work with PDF Packages, but with
plain attachments. You could set the Viewer Preferences in such
a way that the attachments panel is always opened.
br,
Bruno
Bill Segraves
<snip>
> But Adobe Reader 8 does something nasty: if I fill in some fields in the
> form and then switch to one of the other pdfs in the package, the form
data
> I've entered is lost when I return to the form. As far as I can tell,
this
> is a Reader problem, not an iText problem.
Adobe might view this as a feature. After all, Adobe wants every user to buy
the full distribution of Acrobat to get the features provided by Acrobat
that are not provided with Reader.
> Reader 8 doesn't even warn
> I'm going to lose data (7.08 does) if I close a simple fillable form.
>
So, you should save the form data before you close the form. In order to do
this with reader, you'll need to modify the PDF so the form data can be
submitted to a server-side script that captures the data for you.
> With Reader 7.08, switching between the attachments is less convenient,
but
> you can do it without losing form data. (Looking at 8 again, I see I can
> right-click on one of the pdfs and pick open in a new window. Then it
> behaves like version 7.)
Of course, you'll still lose the form data when you close the PDF, if you
have not saved it before closing the PDF.
Cheers,
--
Bill Segraves
Bob Babcock
>> But Adobe Reader 8 does something nasty: if I fill in some fields in
>> the form and then switch to one of the other pdfs in the package, the
>> form data I've entered is lost when I return to the form.
> Adobe might view this as a feature. After all, Adobe wants every user
> to buy the full distribution of Acrobat to get the features provided
> by Acrobat that are not provided with Reader.
Actually, most of our users have at least Acrobat 7 standard. They'll be
upgraded to 8 whenever the media shows up. But right now we don't have any
copies of 8 other than Reader.
The problem with packages is that I expected the navigation panel to act
like tabs in a web browser, but instead it's like an old browser that
closes the old view when you open another one unless you specifically ask
for a new window. (The "Show each document in its own window" option has
no effect here.) I get a warning that I won't be able to save the form
when I first modify a field, but that's not when the warning is most
needed. I expect a similar warning when I try to close a modified form
without first using the print or submit buttons.
> So, you should save the form data before you close the form. In order
> to do this with reader, you'll need to modify the PDF so the form data
> can be submitted to a server-side script that captures the data for
> you.
The form has a submit by email button that works, and for this application,
seems adequate. More importantly, the people who would have to implement a
server-side script are busy with other tasks.
Thanks for your comments. Given vacation schedules, I doubt much more will
happen until January.
lakhana...@gmail.com
I am using pdftk to dump data fields from form pdf but i want xfa data from form pdf in php. Please suggest me any solution.
Thanks
Peter Flynn
Hash: SHA256
http://www.pdfunit.com/en/documentation/xml/utilities/extract-xfa.html
///Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYh7YvAAoJEHt9ZfbX6inQslwH+wRjTyeg6ZrAhgDR43cTFXO5
AvVH19Efv1QPNY+S2BKsqyCQDvaxssrrKqTvPlL/mIJ4vIbjRvs39OWdkpdmPEd+
gXdC9PlaY/KhOlRiE3EF+oXujAkAuIKZdlkg6lPpR+u+hS727ZNWiztehYKc0noD
Eg+eYCTjygvgjHHF2ok7SaJFePcHiTm408Tq4PhmN1Rw+InJAlKU42h6x8VwlFtl
nvtOcdRU+cEid4IyNgDj723Tmb0Lg5vLKNUFIlUfn382cgoVCv/Ru1NLVMVDzjaF
bEK8NXMp6f1uVVTw1nj4Py/VTyYEymDNy/meITKb+JxunMK3Lxa0Fo/EKSZenMo=
=uO3G
-----END PGP SIGNATURE-----