Leonard,
Please see inline responses below.
Thanks and best regards,
Bill Segraves
----- Original Message -----
From: "Leonard Rosenthol" <leonardr@...>
To: "Post all your questions about iText here"
<itext-questions@...>
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
> > http://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 http://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
|