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.

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.

iText can fill PDFs created with Designer, pdftk is based on an older
iText version that didn't yet support it. You can create the form in
Acrobat (not Designer) and have pdftk to fill it.

Paulo

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.
>
> 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.

Bob Babcock <wssddc@nospam.gis.net> wrote:

>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.

If I understand right what you want to do, then a FDF file should do it
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

"ReFOB" <ReFOB@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...
----------------------------------------
Aandi Inston  
Please support usenet! Post replies and follow-ups, don't e-mail them.

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

"ReFOB" <ReFOB@web.de> wrote:

>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?

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.
----------------------------------------
Aandi Inston  
Please support usenet! Post replies and follow-ups, don't e-mail them.

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

Aandi Inston wrote:
> "ReFOB" <ReFOB@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.

"Bill Segraves" <bill.segraves@gmail.com> wrote in
news:1166120009.083089.130580@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.

Bob Babcock wrote:
> 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

Bruno Lowagie <bruno.lowagie@nospam.ugent.be> wrote in 
news:4582ca09$0$1128$ba620e4c@news.skynet.be:

> Bob Babcock wrote:
>> 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

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...)

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.

"Bob Babcock" <wssddc@nospam.gis.net> wrote in message
news:Xns989BA8138E83Bwssddcgisnet@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; ..."

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" <segraves_f13@mindspring.com> wrote in message
news:bSZgh.273$w91.43@newsread1.news.pas.earthlink.net...
> "Bob Babcock" <wssddc@nospam.gis.net> wrote in message
> news:Xns989BA8138E83Bwssddcgisnet@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

"Bill Segraves" <segraves_f13@mindspring.com> wrote in
news:bSZgh.273$w91.43@newsread1.news.pas.earthlink.net: 

> 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...

Bob Babcock wrote:

> 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

Bruno Lowagie <bruno.lowagie@nospam.ugent.be> wrote in
news:4584e8d3$0$5524$ba620e4c@news.skynet.be: 

> 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.

Bob Babcock wrote:

> 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

Bruno Lowagie <bruno.lowagie@ugent.be> wrote in
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.

Bruno Lowagie <bruno.lowagie@ugent.be> wrote in
news:em8nan$hos$1@gaudi2.UGent.be: 

> 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.)

Bob Babcock wrote:
> 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

"Bob Babcock" <wssddc@nospam.gis.net> wrote in message
news:Xns989FAB588DFCwssddcgisnet@208.49.80.252...
<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

"Bill Segraves" <segraves_f13@mindspring.com> wrote in
news:DZeih.1777$X72.1576@newsread3.news.pas.earthlink.net: 

>> 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.