I have developed a PDF web form to manage records in a database.

I have a corresponding asp script to return either the values for the
form fields, via the FDF format, or a redirect to another HTML page,
e.g. showing a message, e.g., "Record not found".

My PDF Submit button action refers to "ProcessForm.asp#FDF", which is
my server script.

When I enter a new record with the form (IE6,Acrobat6Pro), the script
adds the record and then returns a "text/html" response with a message
in it to the browser.
Although the script adds the record, I never see the HTML page - the
browser just keeps the Acrobat Reader displayed in the browser with
the form instead of displaying the HTML.

Similarly, if a new record is found to exist in my database, the
script does Response.Redirect to another HTML page, which is also
never shown by the browser, which stubbornly retains the Acrobat form
in the frame.

Sometimes, though, I want to just populate the form with existing data
by returning "application/vnd.fdf" data to the browser.

So my questions are:

How do I configure an Acrobat form to handle either
"application/vnd.fdf" data or "text/html" data coming back from the
server and do the correct thing (prefill the form, or cause the
browser to display the HTML page)?

Should I remove the #FDF from the action, or will this prevent the fdf
from performing the form fill function using the FDF data?

Rick

google@westernwares.com (hogwell) wrote:

>Should I remove the #FDF from the action, or will this prevent the fdf
>from performing the form fill function using the FDF data?

I don't think you can have it both ways. Either use #FDF and return an
FDF always; or don't use #FDF and don't return an FDF ever.

One approach is to return a message field to the PDF, via an FDF.
----------------------------------------
Aandi Inston  quite@dial.pipex.com http://www.quite.com
Please support usenet! Post replies and follow-ups, don't e-mail them.

"hogwell" <google@westernwares.com> wrote in message
news:28faf3e.0402131543.730e8609@posting.google.com...
> I have developed a PDF web form to manage records in a database.
>
> I have a corresponding asp script to return either the values for the
> form fields, via the FDF format, or a redirect to another HTML page,
> e.g. showing a message, e.g., "Record not found".
>

You might try leaving off the #FDF and returning your response with the
appropriate Content-Type for the intended use of it at the client side of
the transaction.

> My PDF Submit button action refers to "ProcessForm.asp#FDF", which is
> my server script.
>

What is the rest of the URL, e.g., the beginning of it?

> When I enter a new record with the form (IE6,Acrobat6Pro), the script
> adds the record and then returns a "text/html" response with a message
> in it to the browser.

Drop the #FDF and return the HTML response as Content-Type: text/html. This
works fine with my Perl scripts. YMMV with ASP scripts.

> Although the script adds the record, I never see the HTML page - the
> browser just keeps the Acrobat Reader displayed in the browser with
> the form instead of displaying the HTML.
>
> Similarly, if a new record is found to exist in my database, the
> script does Response.Redirect to another HTML page, which is also
> never shown by the browser, which stubbornly retains the Acrobat form
> in the frame.
>

See above, re: #FDF

> Sometimes, though, I want to just populate the form with existing data
> by returning "application/vnd.fdf" data to the browser.
>

Content-Type: application/vnd.fdf

> So my questions are:
>
> How do I configure an Acrobat form to handle either
> "application/vnd.fdf" data or "text/html" data coming back from the
> server and do the correct thing (prefill the form, or cause the
> browser to display the HTML page)?
>

See above.

> Should I remove the #FDF from the action, or will this prevent the fdf
> from performing the form fill function using the FDF data?
>

That's what I'd try if I were you. Works fine here.

Good luck!

Cheers.
--
Bill Segraves

Thanks, folks, for your input on this.

In summary: My setup (Acrobat 6Pro/IE6) submits forms inconsistently
and much differently than behaviour in Netscape, and I'm trying to
determine a way to program around this on the server - or at least
understand the way Acrobat works with the web and how it differs from
processing HTML forms.

My server script, based on the submitted form data, returns either
"Content-Type: text/html" (to tell the browser to switch out of
Acrobat and display the html) or "Content-Type: application/vnf.fdf"
(to prefill the pdf form and allow the user to make changes to the
data and resubmit).

So far, this is what I've discovered:

If my submit button action is "ProcessForm.asp#FDF", my script runs as
it should (this is a relative url). If it returns FDF, the form is
prefilled properly. If it returns HTML, or redirects to an HTML page,
the IE6 browser ignores it and keeps displaying the Acrobat form,
although the script runs correctly and returns Status Code 200 with
the text/html content.

If I change my submit button action to "ProcessForm.asp", the form
submit is not performed at all, with no POST done to the web server
(browser sends nothing out).

My understanding of the docs is that Steve's comments are correct and
that this should work similar to an HTML form. The #FDF seems to be
required for the form to submit at all (at least in IE6).

To make things more complicated, the same form submitted the same way
in Netscape 7.1 with the Acrobat 6.0 Reader plugin works completely
differently - it performs the "SUBMIT" TWICE!, even without the
"#FDF"!
On the server, the first SUBMIT worked correctly, adding a record to
the database.
The second unwanted SUBMIT produces a "Record Already Exists" error,
since this looks to the server like a second request to add the same
record - so that is all the user sees (the error message) - not good.

To clarify, here is an excerpt from my IIS web server log for these
two scenarios:

Running IE6 on XP Pro, My FillForm.asp script redirects to the pdf
file on the server...
20:22:19 GET /FormSite/FillForm.asp FillMode=Add 302
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.0.3705)

The redirect causes IE6 (and/or Acrobat6) to fetch the pdf form,
fine...
20:22:20 GET /FormSite/Forms\FormSite\Preadmit3.pdf t=1339 200
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.0.3705)

What's this? A second "Partial Get" (206) request for the pdf file
from the Acrobat control... Oh well, no damage done - it displays ok
in Acrobat.
20:22:28 GET /FormSite/Forms\FormSite\Preadmit3.pdf t=1339 206
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.0.3705)

I fill out the pdf form to add a new record, hit submit and...
20:23:18 POST /FormSite/ProcessForm.asp - 200
Mozilla/4.0+(compatible;+Adobe+Acrobat+Control+Version+6.00+for+ActiveX)

The script runs successfully, returning text.html that is ignored by
the Acrobat Control, which continues to display the pdf form instead
of the returned html page.

Ok, now I try this from Netscape 7.2 on a different XP Pro machine..

20:46:16 GET /FormSite/FillForm.asp FillMode=Add 302
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.4)+Gecko/20030624+Netscape/7.1+(ax)

As with IE, My FillForm.asp script redirects to the pdf file on the
server...
20:46:23 GET /FormSite/Forms\FormSite\Preadmit3.pdf t=2776 200
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.4)+Gecko/20030624+Netscape/7.1+(ax)

I fill out the pdf form to add a new record, hit submit and...
20:47:19 POST /FormSite/ProcessForm.asp - 200
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.4)+Gecko/20030624+Netscape/7.1+(ax)

This works and returns HTML - so far so good.

SURPRISE - Netscape SUBMITs the form again *for no reason!*
20:47:21 POST /FormSite/ProcessForm.asp - 302
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.4)+Gecko/20030624+Netscape/7.1+(ax)
This time, the script gets a duplicate form submit and redirects (302)
to the error page...not good

20:47:21 GET /FormSite/Error-RecordExists.asp from=ProcessForm 200
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.4)+Gecko/20030624+Netscape/7.1+(ax)
Unlike IE6, Netscape *does* displays the HTML redirected error page,
though.
If only it didn't submit *twice*. (Imagine if this were a credit card
purchase form!)

---

BTW, I have also discovered another big difference between HTML form
submits and PDF form submits: HTML GET requests include all the form
fields, even if they are blank, e.g.
GET "ProcessForm.asp?Field1=avalue&Field2=&Field3=avalue"

PDF forms, on the other hand, send only fields that have a value in
them:
GET "ProcessForm.asp?Field1=avalue&Field3=avalue"

This means that the form field names on an Acrobat form cannot be
determined from the GET request alone, but must be known in advance by
the server CGI script.

I knew I'd have to stand on my head to work with an "acrobat", but
this is ridiculous! (Is this product mature yet?)

I'm coming to the conclusion that web PDF forms can *only* be used to
prefill themselves and are not able to interact predictably with a web
server like an HTML form.

"hogwell" <google@westernwares.com> wrote in message
news:28faf3e.0402141413.63a91827@posting.google.com...
> Thanks, folks, for your input on this.
<snip>
> My understanding of the docs is that Steve's comments are correct and
> that this should work similar to an HTML form. The #FDF seems to be
> required for the form to submit at all (at least in IE6).
>

Perhaps some of the PDF experts can enlighten us on when #FDF is required
and when it is not required. My forms without #FDF work fine for Acrobat
(&Reader) 3 through 5.05, and IE up to 5.5. I can't say what IE6 does, as
I've avoided it, having heard of bad experiences with it and PDFs early on.
IIRC, you confirmed the forms at http://segraves.tripod.com/index3.htm
worked with your setup. Did they work with IE6 and Reader 6?

> To make things more complicated, the same form submitted the same way
> in Netscape 7.1 with the Acrobat 6.0 Reader plugin works completely
> differently - it performs the "SUBMIT" TWICE!, even without the
> "#FDF"!
> On the server, the first SUBMIT worked correctly, adding a record to
> the database.
> The second unwanted SUBMIT produces a "Record Already Exists" error,
> since this looks to the server like a second request to add the same
> record - so that is all the user sees (the error message) - not good.
>

You should trap the errors in a manner that does not display them to the
user. Why give the bad guys any information they could use to exploit
security holes in your system?

<snip>
> BTW, I have also discovered another big difference between HTML form
> submits and PDF form submits: HTML GET requests include all the form
> fields, even if they are blank, e.g.
> GET "ProcessForm.asp?Field1=avalue&Field2=&Field3=avalue"
>

Allowing GET requests is not a good idea anyhow. Why not use POST?

> PDF forms, on the other hand, send only fields that have a value in
> them:
> GET "ProcessForm.asp?Field1=avalue&Field3=avalue"
>

I can't say for Acrobat 6, as mine is still in the box, awaiting a
compatible computer. OTOH, for earlier version of Acrobat, it is possible
for you to configure the submit action to include or not include blank
fields.

Generally, IMO, it's a good idea to *not* send blank fields if you wish for
a user to be able to fill a form in multiple sessions, saving chunks of
input data for the form for later import into the form. If you try the
sample.pdf form at http://segraves.tripod.com, you'll see that you can fill
out the form in groups of fields, e.g., name data, address data, etc. The
FDFs from the submit and server-sdie processing will be independent,
allowing you to import the sets one at a time, without unwanted blanks
clobbering previously entered data.

> This means that the form field names on an Acrobat form cannot be
> determined from the GET request alone, but must be known in advance by
> the server CGI script.
>

Definitely not true. It is not necessary at all for the server-side CGI
script to "know" the field names in the PDF form. OTOH, if you want to know
*all* of the field names in a form, you must provide a "submit" action that,
well, submits *all* of the fields, including blank fields.

> I knew I'd have to stand on my head to work with an "acrobat", but
> this is ridiculous! (Is this product mature yet?)
>

I should hope not. Like many software products, Acrobat is evolving to
respond to the needs/opportunities of the marketplace.

> I'm coming to the conclusion that web PDF forms can *only* be used to
> prefill themselves and are not able to interact predictably with a web
> server like an HTML form.

On the contrary, PDF forms give you an opportunity to precisely control the
appearance of what is displayed. HTML, on the other hand, doesn't give you
this degree of control in the client browser.

Cheers.
--
Bill Segraves

"Bill Segraves" <segraves_f13@mindspring.com> wrote in message
news:p9AXb.5100$W74.916@newsread1.news.atl.earthlink.net...
> "hogwell" <google@westernwares.com> wrote in message
> news:28faf3e.0402141413.63a91827@posting.google.com...
<snip>
> > This means that the form field names on an Acrobat form cannot be
> > determined from the GET request alone, but must be known in advance by
> > the server CGI script.
> >

I should have been more precise in my response. From your statement, I infer
you mean that the programmer must know the field names in advance. This is
what I stated is not true, as it is possible to get the field names
programmatically, as long as they are part of the URL-encoded string of
name=value pairs resulting from an HTML submit action.

>
> Definitely not true. It is not necessary at all for the server-side CGI
> script to "know" the field names in the PDF form,

[as said server-side script could have code that extracts the field names
programmatically]

> OTOH, if you want to know
> *all* of the field names in a form, you must provide a "submit" action
that,
> well, submits *all* of the fields, including

[those that are blank.]

Cheers.
--
Bill Segraves

Aandi,

> I don't think you can have it both ways. Either use #FDF and return an
> FDF always; or don't use #FDF and don't return an FDF ever.
> 
> One approach is to return a message field to the PDF, via an FDF.

I think you are right... the only reliable way to handle an Acrobat
form on a web server is to use #FDF to prefill field values with an
FDF response - period.
(at least I hope this much is consistent across reader versions and
browsers!)

I might have to *require* pdf forms to have a special "message" field
that is only used for displaying messages to the pdf form user like,
"record added",
or "record found". I did not want to have "special" fields in the
forms that my server will process.

Since redirects and HTML are not reliable server response options for
the Acrobat Reader in the browser, it will have to be up to the user
to manually navigate away from the pdf form.

It seems form handling with Acrobat is very limited (and different)
compared to HTML forms.

- Rick

Bill,

> Perhaps some of the PDF experts can enlighten us on when #FDF is required
> and when it is not required. My forms without #FDF work fine for Acrobat
> (&Reader) 3 through 5.05, and IE up to 5.5. I can't say what IE6 does, as
> I've avoided it, having heard of bad experiences with it and PDFs early on.

If the different versions of Acrobat Reader behave so differently re:
Form submittal, this is a real problem, I would think.

> IIRC, you confirmed the forms at http://segraves.tripod.com/index3.htm
> worked with your setup. Did they work with IE6 and Reader 6?

Using IE6 and Acrobat6Pro on your sample, I am prompted to download
the .pl file, which I think is in FDF format?

What "action" do you have in this form? (with or without the #FDF?)
What Content-Type are you specifying in your response?

> 
> You should trap the errors in a manner that does not display them to the
> user. Why give the bad guys any information they could use to exploit
> security holes in your system?

I think you misunderstand... this is not about errors that users
should not see. This is about basic user feedbackk and website
navigation.
For example, this is what I *wish* I could do with a pdf form:

The user fills out a key field in the pdf form to perform a search.
Submit - the cgi returns FDF to prefill the form with the found data,
or redirects to an HTML page "Record not found".
If the record was found, the user might change a field or two, then
resubmit to update the database. After doing this, I'd like the cgi to
redirect the user to an HTML "success page", "Your update was
successful."

If returning FDF to an Adobe form is the only reliable option in both
IE and Netscape, this workflow is not do-able.

> I can't say for Acrobat 6, as mine is still in the box, awaiting a
> compatible computer. OTOH, for earlier version of Acrobat, it is possible
> for you to configure the submit action to include or not include blank
> fields.

The pdf forms that I have to work with have the form submit button
action set to HTML - All Fields.
I notice that if I check "Only send specific fields", I can get to
another dialog that has a checkbox "Send empty fields", so perhaps
that is what you meant, so there might be a way to set this
non-default option. You'd think that "submit all fields" would do just
that, empty fields and all. (And, in my case, I have to work with
simple pdf forms with one submit button with the default properties
only.)

> Generally, IMO, it's a good idea to *not* send blank fields if you wish for
> a user to be able to fill a form in multiple sessions, saving chunks of
> input data for the form for later import into the form. If you try the
> sample.pdf form at http://segraves.tripod.com, you'll see that you can fill
> out the form in groups of fields, e.g., name data, address data, etc. The
> FDFs from the submit and server-sdie processing will be independent,
> allowing you to import the sets one at a time, without unwanted blanks
> clobbering previously entered data.

Good point, but how can the user ever blank out a filled field then?
What if you want an application that wants to "discover" all the field
names when the form is submitted, e.g., to create a database table?

> > This means that the form field names on an Acrobat form cannot be
> > determined from the GET request alone, but must be known in advance by
> > the server CGI script.
> >
> 
> Definitely not true. It is not necessary at all for the server-side CGI
> script to "know" the field names in the PDF form. OTOH, if you want to know
> *all* of the field names in a form, you must provide a "submit" action that,
> well, submits *all* of the fields, including blank fields.

As I mentioned above, this does not seem to be the default for "All
Fields", at least with Acrobat 6. IMO, default behavior should be like
an HTML form submit, with all the fields.

> 
> > I knew I'd have to stand on my head to work with an "acrobat", but
> > this is ridiculous! (Is this product mature yet?)
> >
> 
> I should hope not. Like many software products, Acrobat is evolving to
> respond to the needs/opportunities of the marketplace.

IMO, forms handling should be based on the very predictible behavior
of HTML forms in browsers - this should be the default behavior of a
pdf form.
If Adobe wants to add other types of behavior for the "marketplace",
like the
FDF prefilling, removing blank fields from the submit, XFDF, that's
fine.
Certain flaws, like the double-submitting forms in Netscape, ignoring
HTML responses in IE, etc. are just plain unacceptable for real
deployment in a web environment and have nothing to do with user's
"needs/opportunities".

> > I'm coming to the conclusion that web PDF forms can *only* be used to
> > prefill themselves and are not able to interact predictably with a web
> > server like an HTML form.
> 
> On the contrary, PDF forms give you an opportunity to precisely control the
> appearance of what is displayed. HTML, on the other hand, doesn't give you
> this degree of control in the client browser.

I agree - the WYSIWYG display of pdf forms is the *only* reason I am
trying so hard to make them work as well as HTML forms do with my web
application.

Thanks again for your feedback...
Rick

"hogwell" <google@westernwares.com> wrote in message
news:28faf3e.0402151035.2d148834@posting.google.com...
> Bill,
<snip>
> If the different versions of Acrobat Reader behave so differently re:
> Form submittal, this is a real problem, I would think.
>

IMO, it's not so much Acrobat Reader differences among version, but rather,
failure of browser developers to comply with established standards.

> > IIRC, you confirmed the forms at http://segraves.tripod.com/index3.htm
> > worked with your setup. Did they work with IE6 and Reader 6?
>
> Using IE6 and Acrobat6Pro on your sample, I am prompted to download
> the .pl file, which I think is in FDF format?
>

Yes. I did not "force" a filename because it would not work reliably for all
the browsers for which I tested it. The default appears to be the filename
of the script that processed the form data.

> What "action" do you have in this form? (with or without the #FDF?)

Without #FDF, e.g., http://domain/cgi-bin/script.pl

> What Content-Type are you specifying in your response?

Content-Type: text/plain

in the examples at Tripod. This is because I wish for the user to be able to
capture and save the FDF that is returned to the client (browser).

If I wanted the returned data to go directly into another PDF, I'd use
Content-Type: application/vnd.fdf. In this case, IIRC, the #FDF *would* be
required on the URL for the action.

You can test this for yourself on your system. If you do a Google groups
search for "segraves ms access win32::odbc", you'll see an example (No. 6 in
the thread) I posted that explores a similar problem.

>
> >
> > You should trap the errors in a manner that does not display them to the
> > user. Why give the bad guys any information they could use to exploit
> > security holes in your system?
>
> I think you misunderstand... this is not about errors that users
> should not see. This is about basic user feedbackk and website
> navigation.

With all due respect, I don't think so. IIRC, the example you gave was
related to multiple (spurious) queries of a database associated with your
submit actions. IMO, you should test any query for a valid response without
exposing the user to the invalid responses.

> For example, this is what I *wish* I could do with a pdf form:
>
> The user fills out a key field in the pdf form to perform a search.
> Submit - the cgi returns FDF to prefill the form with the found data,
> or redirects to an HTML page "Record not found".

Why not a PDF that displays the desired data. All you have to do provide a
PDF that is the "error message" PDF with a field for the error message(s),
put the error message in the corresponding field in the error FDF, as well
as the URL of the error PDF in the /F spec of the returned error FDF. The
error message fields could also be incorporated into the PDF that displays
the response to the query.

> If the record was found, the user might change a field or two, then
> resubmit to update the database. After doing this, I'd like the cgi to
> redirect the user to an HTML "success page", "Your update was
> successful."
>

See above.

<snip>
> The pdf forms that I have to work with have the form submit button
> action set to HTML - All Fields.

Are you not allowed to change it?

> I notice that if I check "Only send specific fields", I can get to
> another dialog that has a checkbox "Send empty fields", so perhaps
> that is what you meant, so there might be a way to set this
> non-default option. You'd think that "submit all fields" would do just
> that, empty fields and all.

I wouldn't speculate on that. The options are selectable and testable. I'd
recommend you use what is the best fit to your requirements.

> (And, in my case, I have to work with
> simple pdf forms with one submit button with the default properties
> only.)

IMO, you should be glad to have the configurable options. I certainly
wouldn't trust any developer to select defaults that are appropriate for
*me*.
<snip>

> Good point, but how can the user ever blank out a filled field then?

Use a reset form action.

> What if you want an application that wants to "discover" all the field
> names when the form is submitted, e.g., to create a database table?

Fine. If the PDF has been designed to submit only fields that are not blank,
then you could enter some data in each field prior to submitting it.

<snip>

> IMO, forms handling should be based on the very predictible behavior
> of HTML forms in browsers - this should be the default behavior of a
> pdf form.

Adobe seems to think otherwise.

My experience has been that the behavior of HTML forms in browsers is not
very predictable at all, as some browser developers do not comply fully with
established standards. You might take your favorite example of a good HTML
page and submit it to W3C's validator and see how many errors it has.

<snip>
> Certain flaws, like the double-submitting forms in Netscape, ignoring
> HTML responses in IE, etc. are just plain unacceptable for real
> deployment in a web environment and have nothing to do with user's
> "needs/opportunities".
>

Did it ever occur to you that M$ might have some responsibility in this
area?

<snip>

> I agree - the WYSIWYG display of pdf forms is the *only* reason I am
> trying so hard to make them work as well as HTML forms do with my web
> application.
>

Well, I generally use PDF forms when I wish to provide a high degree of
control over the appearance of a *printed* form. HTML is not well-suited to
this purpose, as the printed output is dependent of the configuration of the
user's browser.

> Thanks again for your feedback...
> Rick

You're very welcome.

Cheers.
--
Bill Segraves