----- Original Message ----- From: "Leonard Rosenthol" <[EMAIL PROTECTED]> To: "Post all your questions about iText here" <[email protected]> Sent: Saturday, 28 April, 2007 7:34 PM Subject: Re: [iText-questions] Formular Submit from PDFonlyworkswhileopenedin Browser
> I think that the EULA and Adobe's position on the EULA and use of > Reader in such environments speak for themselves. I agree. Unfortunately, IMO, Adobe has taken a posture that severely limits the use of Reader for legitimate purposes using features that Adobe has provided. > In addition, the > "Reader Enablement" features available in Reader 7 and later also > provide much greater capabilities for users than the "hack" of local > submission ever could. While this may be true for many cases, it is not true for the development activities in which I am engaged. Example: Consider an lineage society application such as those found at www.sar.org. The "Reader Enablement" is totally irrelevant to the solution to the problem of shifting all genealogical data by a generation (or two) to accomodate the preparation of an application for a son (or grandson) of the original applicant. If you are aware of a way to do this with Reader (any version), other than "submitting" to a server-side script that programatically shifts the data and returns same as FDF/XFDF to the client-side browser, I'd certainly like to know about it. Leonard, I detect a hint of "hostility" among the Adobe culture re: referring to a "submit" action to a "localhost" server as a "hack." WADR, it's not a hack. Submitting to a URL is, IMO, a fundamental capability that AcroForms MUST be able to accomodate in order to work and play nicely on the WWW. Whether or not the URL includes localhost, 127.0.0.1, or any private IP address is irrelevant. In fact, texting with a localhost-based server is far more efficient than testing with a remote server. > These are the directions that we are taking > the Acrobat/Reader family. > I understand. Now, IMO, if you could include in the directions an embedded httpd server as part of the Reader extensions, you'd be going a long way towards providing a product that works as it should with dynamic forms. > If you wish to develop for other viewers - that's certainly your > choice as a developer and business person. Actually, it's not my choice at all. The market demands that AcroForms work, in some way, with viewers other than Reader, e.g., the default viewer for Mac OS X, and the various FOSS viewers that come with recent Linux distrubutions. Personally, I'd prefer by far that Adobe play nicely with customers by allowing the full use of all of the capabilities they include in their software. 'Nuff said. I think this thread has reached a good stopping point. Best regards, -- Bill Segraves ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://itext.ugent.be/itext-in-action/
