On Apr 28, 2007, at 11:18 PM, William Alexander Segraves wrote:
> Example: Consider an lineage society application such as those
> found at
> 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?
> 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.
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.
> 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 WWW.
I agree 110%.
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.
> Whether or
> not the URL includes localhost, 127.0.0.1, or any private IP
> address is
> irrelevant. In fact, texting 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.
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!
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. Now, IMO, if you could include in the directions an
> embedded
> httpd server as part of the Reader extensions, you'd be going a
> long way
> towards providing a product that works as it should with dynamic
> forms.
>
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!
> 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.
And while you're at it - you might also suggest support for XFA.
> 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.
Leonard
-------------------------------------------------------------------------
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/
