PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
At 6:12 PM -0400 7/11/03, Todd Kueny wrote:
A lot of customers have been asking us for the ability to convert Acrobat Forms directly to HTML.
Interesting. I've talked to more folks who want the opposite - HTML or Word forms to PDF forms...
We have put together an automated web service that automatically consumes an uploaded Acrobat PDF form and converts it to a corresponding set of HTML pages with links, text fields, buttons, etc. - through the browser the user sees JPG's for each PDF page and HTML fields (text, radio, etc.) appear where the Acrobat Form fields are defined.
So you're just rasterizing the PDF for the background, and then doing field conversion. OK - that can work.
What are you doing about field scripts, including formatting & calculation? Are you converting all attributes?
1) What kind of data binding is appropriate for such HTML form fields?
In terms of a live binding or a "at Submit time" binding? And why wouldn't it be the same as the original PDF?
The FDF model seems to require the entire form field data set be transmitted back and forth between the browser and the sever
No, FDF can include only a subset of fields...
and it would also seem that reader is rather limited in what it can do regarding data saving.
For non-Reader Enabled PDF's that is true, it can't save locally merged data - hence the existance of server-based merging tools.
Doing the same thing directly in a non-Acrobat web server eliminates all the restrictions - but just eliminating restrictions doesn't seem to be enough.
Correct, it does not solve all problems.
For example, you might want to have realtime validation happening at the field level - say a drop down that queries a database so that the choices are always current.
Right. There is no way to do that with non-Reader Enabled PDFs. You can, however, do that in a number of ways with Reader-enabled PDFs or with FULL Acrobat.
2) Forms seem to have the issue that the data fields they collect are time-decoupled from the server, i.e., if I create a form and later I need more data, or a check box becomes a set of radio buttons, I have no way to find all the forms in use and alter them.
I'm not sure I follow you here. The layout & specs for a form (such as whether to use check boxes or radio buttons) is a design time issue, NOT a deployment side issue.
I do agree that such things as "contents of combo boxes" may change between design and deployment - but again, those can be solved when not limited to Reader and non-enabled PDFs.
Leonard -- --------------------------------------------------------------------------- Leonard Rosenthol <mailto:[EMAIL PROTECTED]> Chief Technical Officer <http://www.pdfsages.com> PDF Sages, Inc. 215-629-3700 (voice) 215-629-0789 (fax)
To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
