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