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). 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. In the first prototype, you can fill in a form using browser -> reader communication. http://itext.ugent.be/playground/agreement.html Click on the 'browse courses' button and an HTML window will open. Choose a course, click OK, and the PDF form will be filled in. Why is this useful? We have a catalogue with over 5000 courses, and we can easily let potential students browse this catalog using HTML pages generated using JSP, PHP,...), but we want them to fill out the form in PDF. The second prototype tests the reverse communication: http://itext.ugent.be/playground/talk_to_html.html I didn't really need this for my project, so I didn't elaborate on the example. If you move your mouse over the blank PDF page, you'll discover that there's a blank AcroField next to the OK button. Fill it out, and click OK. The content will appear in the HTML text field. In theory, you could use this reader->browser communication to forward the field data to an applet, and use iText on the client side to create a new PDF to replace the PDF in the object tag. 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. best regards, Bruno ------------------------------------------------------------------------- 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/
