----- Original Message ----- From: "Bruno Lowagie (iText)" <[EMAIL PROTECTED]> To: "Post all your questions about iText here" <[email protected]> Sent: Monday, 30 April, 2007 5:12 AM Subject: Re: [iText-questions] Formular Submit from PDF
> Leonard Rosenthol wrote: > > On Apr 29, 2007, at 8:41 PM, William Alexander Segraves wrote: > > >> 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. > > I must admit that I haven't followed the complete discussion, > but I interpreted the question as: is there a way to run iText > on the client-side (in the browser / with or without connection > to the localhost) instead of on the server-side (risking a > license violation). > No, that wasn't the question at all. The question was about localhost serving of a filled PDF to a client-side browser with Reader 7 operating as a plugin, when the form data has originated from a "submit" action from a PDF, thereby making it possible for the user to save a copy of his filled PDF without having to employ Reader Extensions. Based on Leonard's interpretations of the EULA, it appears that any client-side->server-side->client-side interaction, done solely on the same computer without any required user action such as running a command line script to merge data with the PDF, would be in violation of the Reader 7 EULA. Furthermore, based on Leonard's interpretation, it does not appear to be a violation of the reader 7 EULA if the form data that is being used to fill the PDF did not originate from a submittal from a PDF form, e.g., submittal from an HTML form. OTOH, since Bruno raised that question, it is indeed possible to do what he suggested, i.e. run iText on the client-side, e.g., by embedding Javascript in the returned HTML that executes a "jarred" Java-iText class. IMO, this would not be a good solution for deployment as a web-based application, as there is no way to ensure the client-side user has the required support software installed on his/her computer, or that the user has JavaScript support enabled in the browser configuration. IMO, based on what Leonard wrote, this too would be in violation of the Reader 7 EULA. > I guess William is thinking of some way to send the data > filled in in Adobe Reader to a Java Applet, and have the > applet create a new PDF with all the fields filled in. > I don't see how this would be different from what is > forbidden by the EULA, but for argument's sake, have > a look at the following small prototypes I recently made. > Well, no. That's not what I was thinking. Anyway, thanks for pointing out the examples, Bruno. More on those later, when I've had a chance to review them. <snip> > In practice, this is probably not only in violation with > the EULA, it also has the smell of being a hack. > I'm sure the examples I'm referring to don't work on all > browser/reader versions, and that's sufficient reason for > a NO-GO when I'm asked for my opinion. > I've made these examples because I was asked if it's possible > to establish a communication between HTML and PDF; however, > I wasn't asked for my opinion. Bruno, your opinion is always welcome in any technical discussion in which I am engaged. 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/
