Leonard, Please see inline responses below.
Thanks and best regards, Bill Segraves ----- Original Message ----- From: "Leonard Rosenthol" <[EMAIL PROTECTED]> To: "Post all your questions about iText here" <[email protected]> Sent: Sunday, 29 April, 2007 2:45 AM Subject: Re: [iText-questions] Formular Submit from PDF > On Apr 28, 2007, at 11:18 PM, William Alexander Segraves wrote: > > Example: Consider a 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. > > I couldn't find the actual form on their site or yours :(. Can you > send me one to look at and maybe then I can make a determination? > Oops! Mea culpa. I should have given you a specific URL. http://www.sar.org/membership/application.html On this page, you'll see several variants of the SAR application, i.e., the Cox program, which is not free, and three others, all free. The file SAR_App.PDF (Reader Enabled) was added recently. It has the Reader Extensions, as you can see. Unfortunately, the developer (unknown) of it used a numbering scheme for the form fields that is different from the SAR980915.PDF (Segraves) scheme that has been in place for nearly 10 years. This makes it impossible for existing import capabilities of the Cox program and the Segraves program(s) to be used to import from data that is exported from the Reader-Enabled PDF form. The SARAppAid (Cox) has been around for several years. It has enjoyed the most widespread use by applicants, including those that are doing multiple applications, e.g., for relatives or for supplemental ancestors. The block copy&paste capability of the Cox program is what makes it very efficient to move data up or down by one or more generations to accomodate adding additional genealogical data. The Bristor form is an MSWord template, also free. Finally, the Segraves forms were the first, AFAIK, among the many lineage and patriotic societies to use fillable PDF forms for applications, having been first deployed almost 10 years ago. These forms were first "hatched" to provide a "free" computer-based application that could be used on any computer with Acrobat Reader. Mrs. Segraves and I gifted the existing form at the SAR web site to the Society; but we never gifted any of the server-side goodies or later forms because SAR was not willing to provide the hosting for the forms and scripts. The form at the SAR web site has none of the server-side goodies that are provided at my Tripod site, http://segraves.tripod.com. The SAR application PDF is now protected with both owner and user passwords; so you'll need a link to an unprotected form if you wish to look at the form. Please let me know privately if you'd like to see an example. Or, you could simply register as a user, and I'll provide the user password and the link to the PDF with the goodies. The best goodie, available only to registered users on request, is a PDF form with multiple "submit" buttons, each of which sends the form data to a (Perl) script that does soemething special with the form data, e.g., move the data up or down by a generation. > > > 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. > > > > I use "hack" in that you are using a feature in a way that it wasn't > really designed (aka localhost). It's not intended to be derogatory > - just that it's nothing we expected. > Hmm? I vaguely recall use of localhost for testing mentioned somewhere in documentation. Regardless, I can see why it wouldn't have been expected, as it is certainly not a potential threat to Adobe's profitability. > Please note, FWIW, that in my pre-Adobe days, mine was one of two > companies that independently developed the first such "localhost > servers" that interacted with Reader to do form filling/saving. Oh, > and mine used iText - which is why I wrote the original form filling > & FDF support for iText. > Thank you for your contributions. Personally, I've been working with iText for a little over a year, and with Acrobat for about 10 years. iText, IMO, has significantly enhanced the value of Acrobat for forms developers. I've read that Adobe views iText as a competitive threat; but hope that view has changed. Clearly, iText has significant value to Adobe, else it wouldn't be distributed with any Adobe products. > > > 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. > > I agree 110%. > The longer know you, the smarter you get. ;-) Seriously, I'm glad we see eye to eye on some Acrobat issues. > However, let me also point out (and I'll probably refer back to this > again) that the official direction for forms for PDF is XFA/ > Designer. While AcroForms isn't going away, we are not making any > investments in it. We are, however, continuing to improve and > deliver better XML-based form technology through XFA. > I've noted this trend. It doesn't surprise me, as I can't imagine a business model (for AcroForms) that would make a lot of profit for Adobe. > > > Whether or > > not the URL includes localhost, 127.0.0.1, or any private IP > > address is > > irrelevant. In fact, testing with a localhost-based server is far more > > efficient than testing with a remote server. > > > > Maybe there is a misunderstanding of the EULA here then... > > First - No one is going to come after you for doing this locally - > and in fact, the software doesn't actually prevent it. > Indeed. The only concern I had about the EULA was that the Reader EULA for Reader 7 (and up, I presume), prohibits the use of Reader on the same computer or network with software that makes it possible to save a filled PDF (thereby circumventing the need for Reader Extensions). I, for one, certainly don't want to invalidate any of my Adobe licenses by producing software that violates the EULA. > Second - you can submit your data to localhost and have the server > return FDF/XFDF (or in the case of an XFA form - XFA/XDP/etc.). No > problems! > Good! This is what I already do. I raised the EULA issue only because I didn't wish to provide software and instructions to users that would facilitate their violation of the EULA, as you've described below. > What we DO wish to prevent via the EULA is the creation (and > distribution) of software that acts as the local server AND DOES THE > SAVE! That is enabling functionality in Reader that it doesn't > normally have in that situation. And if that is all you need, then > the correct solution is "Reader Extensions". > I understand. So, it's O.K. for the "localhost" server-side software to save the form data, as long as the server-side process does not save a copy of the filled PDF. Or, is this restriction really aimed at prohibiting the provision of a "Save/SaveAs" capability via the client-side browser? Is it also O.K. for the "localhost" server-side process to "emit" a filled PDF, e.g., a dynamically-filled PDF via an iText class? As I mentioned before, Reader Extensions are not the complete solution for lineage society applications, as they do not provide the capabilities needed to shift data among generations or to block copy&paste data. > <snip> > > We already offer dynamic forms support via XFA forms. They are VERY > powerful including both single field dynamism as well as entire "sub > forms" that can grow and shrink. Try it - you'll like it! > Perhaps there's a potential solution here for the problems I've described. I look forward to trying it. Do all these capabilities exist with the free Reader, or ar Reader Extensions required to play nicely with them? > > > Actually, it's not my choice at all. The market demands that > > AcroForms work, > > in some way, with viewers other than Reader > > Well, that's something you'll have to take up with the other > viewers. We, obviously, have no control on other viewers. > It's a defensive issue, IMO. I've run into several cases where (Mac) users have tried to use their default viewer to fill in a PDF form, producing an unacceptable PDF form by writing on top of the form fields, not in them, and then blaming Adobe (or me) for the unacceptable consequences. My usual advice: Change your viewer to Reader and your problem will go away. > And while you're at it - you might also suggest support for XFA. > I have no influence over the other viewers. I'm happy with Reader, as a free viewer that supports AcroForms. > > > 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. > > > > I believe we do, and hopefully the info above makes that clear. > Please let me know if there is something I missed. O.K. One thing comes to mind. It seems that Reader 7 does not support an "Import Form Data" action, a capability that WAS provided in all prior versions of Reader that I've tested, i.e., v. 3 through 5 (I haven't tested this assertion with v. 6). Thanks for your insights. 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/
