PDF-Forms is a service provided by PDFzone.com | http://www.pdfzone.com/ __________________________________________________________________
Yes we are looking at the same, our PDF's start out as HTML files but we want to create a stand alone portable PDF which can be sent on from consumer to consumer via email. It appears this PDF will have to have server side scripting as the client side script is not supported by Reader. Formium www.formum.com is looking like being our choice of server side tool to "enable" Reader to send forms, however we haven't talked to anyone using it as yet. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leonard Rosenthol Sent: Sunday, July 13, 2003 2:23 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [PDF-Forms] Re: [PDFdev] Converting PDF Forms to HTML PDF-Forms 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-pdfforms.html To change your subscription: http://www.pdfzone.com/discussions/lists-pdfforms.html
