RE: [xep-support] Cool Tools: PDF Forms

Dave:

> So I 'see' the PDF on the server (and presumably fill it in there),
then 'post' it to the server? Is
that the idea?

.. and ..

> Yes, the 'customer' / end user needs his/her own copy of the filled
form (presumably saved as normal PDF
for Acrobat reader)

Yes, implemented as I described there are two options. One is making a new PDF Form with all the information they submitted in the fields themselves. This is good in cases where the Form capability is needed in the future. I called this "saving" a form.

The other is flattening. I think of it as yanking all the "fields" out from underneath the text typed into the form.

In both cases you return a PDF to the user.

And the form does not have to exist on the server. And in some cases in never does. You can generate a PDF on-the-fly with RenderX to a bytestream and send that bytestream to a browser. No physical file ever exists on the server. Or it can be emailed and the user can use a local PDF reader and not necessarily a browser plug-in. In fact, all PDFs you see (browser or not) are already on your hard drive. They are in a disk cache. The PDf you see here in this example never exists on our server (http://www.renderx.com/demos/applications/w-9.html).

> Yes, that's what I thought. And that's where Adobe make their money.

Agreed, but it is frustrating to us and other PDF-related vendors when Adobe "removes" capabilities they freely granted in the past. We are forced daily to answer questions like "why can't I add comments to PDFs by RenderX, I enabled commenting". We always give the following answer -- "You can add comments, get a better PDF reader like Foxit. If you are not happy with that, you must call Adobe." I just can't wait to see what capability they remove next.

> The issues would be field validation - is it 'real time' or on submission?

Well, for the moment it is server-side (submission) BUT Adobe AcroForms support Javascript. We have support for adding Javascript processing to form fields in the next release. Which mean you will be able to insert a fragment of Javascript in FO that would be attached to a field to do validation among other things.

> Others would be fidelity? Can I make the form look as good as a
printed form (not possible
without lots of work in HTML) which is another strength of PDF.

Certainly, it IS PDF and therefore it can look great. I sent you an example separately from our marketing campaign. Anyone else would like to see this document, drop me an email. It is auto generated with your own information in a personalized form.

Kevin

-----Original Message-----
From: owner-xep-support@renderx.com [mailto:owner-xep-support@renderx.com] On Behalf Of Dave Pawson
Sent: Sunday, July 19, 2009 1:18 PM
To: xep-support@renderx.com
Subject: Re: [xep-support] Cool Tools: PDF Forms

2009/7/19 Kevin Brown <kevin@renderx.com>:
> Dave:
>
> As for use cases ....
>
> Well, we had one implementation

Oh I can see lots of use cases! More than enough. I hate getting a
Word document to fill in
and send back :-)

> As for downloading a PDF to fill-in AND save ...
>
> That is a somewhat no-no if you are using Adobe Reader as your PDF reader. No vendor can implement local saving of form content to disk with the magical "top-secret adobe-only permission" called "reader enablement". The same applies to things like adding comments to PDF. These permissions were removed from Adobe Reader for all vendors except Adobe ... Adobe's own software must create (or modify) the PDF to add such functionality to it.

Yes, that's what I thought. And that's where Adobe make their money.

>
> But ...

:-)

>
> I say "somewhat" because nothing stops one (and our partner is now implementing such things on our site) from accepting the form submission server-side and allowing to "save" or "flatten" a PDF. "Saving" is taking the original document and regenerating a new form with all of the data in the fields the user entered as their default values, then returning that form back to the user.

So I 'see' the PDF on the server (and presumably fill it in there),
then 'post' it to the server? Is
that the idea?

"Flattening" is similar except the data is put into the document in
the stream and not form fields. Programmatically, these are merely
modifications from the original style sheet to a new one and we are
writing a "flatten.xsl" and a "save.xsl" that can be applied to a form
FO/XSL to get the proper XSLs for these operations. So, a user can hit
a "save" button in the PDF, submit the current state of the form data
to the server, it is parsed to XML and then a few XSLs applied to
generate a new PDF that has the submitted data inserted. This is
directed back to the users browser or saved in some busines!

So the user see's a normal PDF, fills it in within the browser then
submits it back to the host.
Exactly what is needed.

> If you create a form and use the URL I sent in the first email, part of this process is already happening. That URL is a FDF/XFDF parser that accepts the form data. It parses it and creates an XML file. That XML is transformed to PDF. In a form we are emailing out, that same program recognizes a special submittal from you and generates a license key for PDF Forms for you but sending the transaction to our license key generator. There a use case and shows we even USE our own software :)

It was the 'what' the end user sees that I was curious about.
I have no doubt that RenderX can put the pieces together!

>
> So, a dynamic form can be generated and emailed as attachments or it can be done server side and the PDF sent directly to a users browser. So you can have tools like "submit" to send the data to a server-based process, or "save" to get a working copy of what you have filled out so far (for yourself or even others to complete), or flatten which would likely be used as part of the submit process, to give the user a completed PDF showing what they entered. And the submittal is merely XML that you can use for any business process you wish.

Yes, the 'customer' / end user needs his/her own copy of the filled
form (presumably saved as normal PDF
for Acrobat reader)

>
> One of our partners is using this to allow internal users to create and send custom letter campaigns. They generate a form with some fields that allow sales and marketing to input the information they want in the letter itself ... some verbiage for the particular campaign. This form is submitted and is transformed into the XSL that is applied to their marketing database to generate 100,000 letters for print.
>
> Hope some of these scenarios catch your eye and maybe can lead to some new ideas.

Most definitely. Form submission has many issues in HTML.
Including saving a local copy.

The issues would be field validation - is it 'real time' or on submission?
Others would be fidelity? Can I make the form look as good as a
printed form (not possible
without lots of work in HTML) which is another strength of PDF.

They are the 'next steps' in form submission that will take xsl-fo
forward in this area.

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html