Previous | Next | (P-PDF) General
Topic: Re: Solution for Saving Forms Needed (Via Email)
Conf: (P-PDF) General, Msg: 99857
From: prodok
Date: 11/6/2003 05:44 AM
Actually, you don't even need a provider like efoview. You can set up
something similar on your own webservers.
What efoview essentially does is, have your users submit the data to
their server, and keep it there with an according identifier. When your
user retrieves the data, it simply gets submitted back, and repopulates
the blank form.
You can do this as well. The key is, again, submitting the data to a
server (that is what Reader is allowed to do). On server-side, you will
most likely fill the data into an according database, and provide a way
to retrieve.
In order to do that, you have various tools available (there are more
around, here is just a short list):
• Any HTML-based forms/database entry application works for retrieving
data. For sending data to the end user, you would create a FDF or an
XFDF file (that's the data format file which goes together with PDF).
Both formats are well-defined, simple text files which do not really
need serious skills to be assembled server-side.
• To make work easier, Adobe has the FDFToolkit (currently not
available for download, but promised to become available again on
Friday...). This is a set of libraries you install on your server,
which give you some high-level functions to read and write FDF files. I
consider it to be a "convenience item", but definitely useful.
• There are some forms design tools which create server-side scripts
for you. A good example is OneForm plus from Amgraf
(http://www.amgraf.com), which creates the server-side scripts for
submitting and central storing. Being a forms design tool, it also
allows you to create an equivalent HTML view of your form which
reads/writes to the same data set, so that in a workflow, you can
either use the PDF view, or the HTML view. Have a look at their demo to
see what I mean.
Besides that, there are some other approaches:
a) Submitting the data to the server, filling out the form
server-sided, and sending back the filled out form to the client.
Here, you do not store any data on the server, but simply use a
server-side process to bring the data together with the form, and then
send that back. The user then can save that version locally. Note,
Reader can save to disk anything it gets from the server; it can not
save changes made during its session, however. This approach might be
more of a choice if you have sensitive data...
For that, you might look at the according tool from activePDF
(http://www.activepdf.com) (I don't have its name available at the
moment), or at FDFMerge from Appligent (http://www.appligent.com).
There is also a new product by A Round Table Solution.
b) Extended rights for Reader.
This approach gives a lot more functionality than simple local saving.
It has several advantages over any server-supported approach, which may
or may not be important:
• You can use the form wherever you need; you do not depend on any
stable internet connection.
• There are definitely no privacy concerns, as everything remains
local
• This approach is much safer and more secure than any network-based
approach
Now, if you are using your forms internally (within your organization),
there are other licencing models by Adobe; it would _definitely_ be
worthwile to contact your Adobe _Enterprise_ sales contact.
Hope, this can help.
Max Wyss
PRODOK Engineering
Low Paper workflows, Smart documents, PDF forms
CH-8906 Bonstetten, Switzerland
Fax: +41 1 700 20 37
or +1 815 425 6566
e-mail: mailto:max@prodok.com
http://www.prodok.com
[ Building Bridges for Information ]
______________________
Shameless Plug:
My next conference appearances and workshops:
• PDFConference 2003 in Anaheim, CA, November 9 to 13, 2003
(http://www.pdfconference.com)
Highlight: Workshop "Connecting PDF and Databases" (NNovember 13;
sign up now)
• And, as always, available for on-site
workshops/tutorials/consulting.
_________________________
> I am working with one company www.efoview.com that has a service where
> you send your forms to their server and have the ability to save,
> edit, and submit the filled-in form as an email attachment. I work
> for a city government, and we are testing another solution from them
> to have the application placed on our server so that we don't have to
> worry about protecting sensitive data. We are testing an employment
> application. (If you use Efoview, tell Jim Su I referred you. He is
> wonderful!)
>
> The costs are fairly reasonable. At this time, we can have 20 forms
> (multi-pages ok) that are "saveable" for $800/year. 50 forms is
> $1,000. Much cheaper than Adobe - $25,000-30,000 for 5 forms.
>
