Rights-Enabled PDF Files

[bigwexi]

Can anyone explain what is needed to create PDF Forms for Acrobat Reader use with "Additional usage rights" such as "JavaScript (which) allows SOAP access in forms".

We are a small office of 4 professionals (Acrobat DC PRO  and Acrobat DC subscribed) with hundreds of Acrobat Reader users of our services.

Technically I guess we need to "distill" a PDF with a licensed Certificate... more details please.

Commercially I hope it is not price prohibitive...

Thanks, Enoch.

[Thom Parker]

Talk to Adobe Sales.  This is something that I believe is done with the AEM server.  And it will be cost prohibitive. 

If you need a PDF to communicate with web service you've created, then I'd suggest using regular HTTP POST instead of SOAP.  A PDF form submit sends an HTTP post, If done through JavaScript the payload can be set as custom XML.  Not an efficient process, but it doesn't require Reader extensions. 

[bigwexi]

Thanks, our Reader clients already submit (FDF PUT their) data to our web server but, of-course, they can't receive anything. In other words, our Readers using regular PDF Forms can't participate in an interactive service via JavaScript powered PDF, what a shame. Otherwise, PDF Forms could have become GUI mainstream.

[Thom Parker]

Why don't they receive anything back from the server?  If it's under your control, then the server script can be modified to return FDF.

[bigwexi]

Background: We are a typical large Home Owner Association, i.e., many members, small office.

Retrieval of FDF data (which our Assoc members submit using their Readers, including images!) works well at our office which uses subscription based Acrobat version mix (STD and PRO).  
However, the same script does not work when run in the Reader.  It relies on the member's web browser.

[bigwexi]

Thanks, our Reader clients already submit (FDF PUT their) data to our web
server but, of-course, they can't receive anything.
In other words, Readers using regular PDF Forms can't participate in an
interactive service via JavaScript powered PDF, what a shame.
We invited an AEM conversation/demo. If the cost of enabling basic PDF Form
rights would be more than just a few cents per copy that would be a
commercial mistake... Interesting.

Regards, Enoch.

[Thom Parker]

Reader has no problem sending submits and recieving the server response. So Reader is not the problem.

It sounds like you have users on Mobile? and using the browser preview to fill forms. Additional rights so you can use SOAP will not help with these cases. In a PDF, SOAP requires JavaScript and an advance PDF viewer that executes the SOAP part of the JavaScript model. 

So, unless you are not tell us something, SOAP and additional Reader Rights won't do anything for you. 

[bigwexi]

Both Acrobat Reader and the PRO similarily send the request to the server -- the Reader via the system's browser, the PRO via its in-built browser. However, only the PRO can import the server's FDF response [header('Content-type:application/vnd.fdf'); ...] into its PDF. Creating a new HTML or PDF browser page does not cover well all applications.

[Thom Parker]

1. Acrobat Pro does not have a built-in browser. It has the ability to send HTTP requests and to receive HTTP responses. This does not make it a browser. 

2. Are you sure the users have Acrobat Reader setup to run in the browser? or are they using the browser PDF viewer?   

3. Are the users on mobile devices? The Mobile Acrobat Reader does things differently than the desktop version. However, it should still handle the return from a submit.  

3. Is the server returning FDF or HTML?  

Only Acrobat Pro, Acrobat Reader, and a small handful of other PDF viewers handle submit operations correctly, or at all.  You need to make sure your users are on a complatible PDF viewer. 

[bigwexi]

2. Originally I was using the PRO's "pre-packaged" Submit function. Today, due to numerous member complaints, it was replaced with the following JavaScript guard which raises an alert if the viewer is not one of the following:
var viewer = app.viewerType;

if (viewer == 'Reader' || viewer == 'Exchange' || viewer == 'Exchange-Pro')
This is something which Adobe needs to address. Web browsers are "eager" to open PDFs though some do pretty bad job in rendering and no one I know can handle Submit. Typical members can't tell which viewer opened the PDF -- the extension, the independent application, ... which leads to confusuion, frustration, ...

3. No Mobile Reader can Submit, not even the one Adobe provides. I wonder why. It's more efficient to send just the PDF data rather than share the entire PDF, and in the mobile world data communication is typically limited.

4. In our info storage/retrieval PDF applications -- storage is by the member Readers via FDF of-course (nothing else is supported), retrieval via FDF too by the office PRO or STD acrobat's. Automagically it then populates the active PDF Form at the office, including "images" which members attached... That should appeal to many PDF developers. I wonder why Adobe does not mention this behavior in their submitForm documentation. It's a "killer application". 

[Test Screen Name]

I don't know how you define cost prohibitive. Remember this can be done by buying Acrobat for all your end users. So to allow it to happen in Reader, Adobe are going to want to reclaim all the lost Acrobat sales, maybe a few hundred. The price of AEM is "by negotation" but rumour suggests 5-6 figures US$. 

[bigwexi]

So to enable the simplest PDF right in the Reader one needs to have expensive AEM server memberfship. That does not make commercial sense to me. 

[Thom Parker]

AEM is for enterprise users, which by definition means they can afford it. 

It's doesn't make sense to use JavaScript to detect a viewer other then Acrobat or Reader.

For two reasons

1. If a 3rd party PDF viewer doesn't implement JS, then the code doesn't do anything because it never runs.

2. If a 3rd party PDF viewer does implement JS, then it will return one of the values you've provided, even though it isn't.

There is no JS method for handling non-compliant viewers, but there is a technique. Cover the PDF pages with something that can be removed with JavaScript. Use a document level script to remove it when the PDF is loaded. If the viewer handle JS, the the page cover will be removed and the user will probably never know it was there. But if the viewer doesn't support JS, then the cover will remain.  You'll find and example of this here:

https://www.pdfscripting.com/public/Lite-Document-Security-Description.cfm

And finally, the Acrobat Mobile Reader does have limited support for form submits. And so does the Readdle PDF Expert viewer.