----- Original Message ----- From: "Leonard Rosenthol" <[EMAIL PROTECTED]> To: "Post all your questions about iText here" <[email protected]> Sent: Monday, 30 April, 2007 4:40 AM Subject: Re: [iText-questions] Formular Submit from PDF
> On Apr 29, 2007, at 8:41 PM, William Alexander Segraves wrote: > >> The localhost server can save the data to it's own data-store all it > >> wants - no problems! It is the creation of a filled-in PDF via the > >> server process that creates the violation. > >> > > > > So, if a Java-iText class is provided that does the merging on the > > client-side of the transaction, separately from the interaction > > between the > > client browser and the "localhost" server, this would be O.K. Right? > > > > If the localhost server communicates in any way with the iText class > that is doing the saving - then you are in violation. Leonard, he scenario I had in mind was this: 1. Client-side browser "submits" to "localhost" server. 2. Localhost server parses submitted data, converting same into FDF/XFDF. 3. Localhost server returns FDF/XFDF in 2 above to client browser. 4. User saves the FDF/XFDF to a file. 5. User executes a command line process, e.g., Pdftk or an iText class, that merges the FDF/XFDF with a fillable PDF. 5(alt). User merges the FDF/XFDF with a fillable PDF with Acrobat. I do not believe the process described in steps 1 - 5 above is in violation of any Reader EULA, although it fits the description in the above statement: "If the localhost server communicates in any way with the iText class that is doing the saving - then you are in violation." Perhaps Leonard meant: "If the localhost server communicates in any way independent of operator action with the iText class that is doing saving of a filled PDF on the computer which is the localhost server, then the user of Reader is in violation of the Reader EULA." IMO, the problem we are having with the Adobe Reader EULA (v. 7 & up?) is that a legitimate use of other software on a localhost server, e.g., Pdftk, iText, to merge FDF/XFDF with a PDF, serving same to the client browser, is deemed by Adobe to be the same as enabling Reader to Save/SaveAs. If this interpretation is allowed to stand, Adobe will be placing every developer who thoroughly tests his products, including testing on a localhost server, in violation of the Reader EULA. As the EULA currently stands, it appears I can do all the testing (of software that creates and saves a filled PDF on localhost servers that I wish to do up to and including Reader 6; but if I wish to test the same processes on Reader 7, I must fire up another computer on my network, or worse yet, deploy the software to a remote host, in order to complete the testing. Pardon the expression for frustration, but it seems to be just plain "dumb" to place such restrictions on developers, who, after all, are licensed to use the full product. Perhaps the problem with the EULA could be fixed by adding an exception for testing by developers, or an exception for licensees of the full distribution of Acrobat, any version. More later, as this issue has not been satisfactorily resolved. 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/
