----- Original Message -----
From: "Leonard Rosenthol" <[EMAIL PROTECTED]>
To: "Post all your questions about iText here"
<[email protected]>
Sent: Monday, 30 April, 2007 3:02 PM
Subject: Re: [iText-questions] Formular Submit from PDF
<snip>
> > 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.
> >
>
> Also correct. If you submit from an HTML form and have your
> localhost server return a filled PDF - that's also fine (and in fact,
> a wonderful thing!).
This is the workaround I've developed for systems that don't have Reader at
all, e.g., Knoppix 5.x live Linux CD.
1. Server-side script emits HTML with three frames
a. Top frame contains an HTML form for entry of the form field that is
to be filled
b. Bottom-left frame contains an image map overlaid on a JPEG image of
the target PDF, each hot zone of which is defined something like
<AREA SHAPE="rect" COORDS="513, 38, 575, 49"
HREF="http://localhost/cgi-bin/sarapp_script_v2.pl?NatNo="; ALT="NatNo"
TARGET=top>
There are over 170 such hot zones in the current example, one for each form
field in the target PDF form. The COORDS are extracted directly from the
iText source that was used to generate the PDF form, using a Perl program
that parses the iText source. The JPEG of the PDF form was generated with
ImageMagik.
The above describes just one page of the 2-page form. The second page would
be of similar size, re: no. of form fields.
c. Bottom-right frame contains the merged PDF, which has been produced
and saved on the server-side of the transaction. The PDF is displayed with
whatever plugin is used as the default viewer.
So, based on Leonard's interpretation above, this is "fine (and in fact,
a wonderful thing!)", although it is, IMO, an "ugly hack" in view of what
could be done very neatly with Reader and proper server-side support.
Now, while this appears to be completely compliant with the Reader 7 EULA,
it seems to me to be a bit silly to have to resort to such a scheme to get
around a EULA limitation that is aimed at protecting the Reader Extensions'
marketability, especially when Reader, with or without the Reader
Extensions, is incapable of doing some of the things that need to be done,
e.g., shifting genealogical data up or down by one or more generations.
OTOH, perhaps all I need to do is add the appropriate "submit" actions to a
Reader-Enabled form. Leonard, is it your opinion that the Reader 7 EULA
would PERMIT localhost serving of a filled AcroForm if said use involves a
form that is Reader-Enabled?
Please note that it is not my aim to circumvent any of Adobe's EULA
limitations; but rather, it is to produce the most efficient products that
operate within the EULA limitations.
Many thanks for your continued interest in this thread.
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/
