I’m having an issue with PDF output being rendered in Adobe Reader’s ‘in browser’ feature from an ASP Classic site.
I have a form with a handful of inputs that trundles off and makes a PDF report. The report renders correctly (all input values accounted for) when saved as a file, but gives a blank screen when displaying in Reader v7.0, and goes straight to a no-input-values report in v8.1.2.
Pressing ‘refresh’ in the browser from here will also display a report indicative of none of the HTML form inputs being carried forward.
Are there any basic mechanics of the
HTML form post-back that I may have
left out?
*The one thing that puzzles m*e is that un-checking the ‘Display in-browser’ option in Adobe Reader and not restarting the browser gives the correct report in both versions.
The other possible issue is something to do with the browser’s ‘Trusted sites’ policy. The domain had been added to the trusted list, and:
The HTML input form shows as a trusted site in the status bar
The in-browser PDF screen displays at ‘Unknown Zone’
To clarify:
If the Reader is uninstalled, the downloaded file is correct
If Reader is installed, and set to not display in browser, the output is correct
If set to display in-browser with Adobe Reader, it
v7.0 – Displays a blank screen. ‘Refresh’ goes to a no-input-value PDF report
v8.1.2 – Displays the no-input-value report
Un-checking the ‘Display in-browser’ option in Adobe Reader and not restarting the browser gives the correct report in both versions
There is a working old production environment, which is capable of displaying the PDF file correctly in-browser with Reader v7.0 on the same machines we’re testing with. The issue described occurs with the same code being set up in a new environment with tighter security control.
The environment also uses older technology, which won’t be upgraded. This includes:
The site is ASP Classic
The code is outputting PDF v1.3
Internet Explorer 6. Yes. 6.
Any ideas on why the report isn't always carrying forward the HTML input?
Any help appreciated,
Thanks.
The ASP page that generates the PDF is not getting the values from the form. That is why it is creating a PDF form with empty values. Ensure that the HTML form directly posts to the ASP script generating the PDF. There should not be any response.transfer or response.redirect or 404 redirection that goes to the PDF-generating ASP script.
Ah, dang.
So it turns out IIS had GZIP compression enabled, and the client has an IE6-only rollout. There's much written about IE6's GZIP incompatibility, and if you're looking to conditionally allow it in IIS, there are some solutions.
The white screen is result of it being an ASP page that posts back, and changes its 'content-type' in the HTTP header (to 'application/pdf') - where IIS decides it should compress it, and fails in IE6.
Adobe Reader 8 does a 2nd request, losing the postback values.
Related
With the latest version of Firefox (107) it is now possible to edit and sign PDF documents within the browser preview window.
But how can I upload an updated version of such a PDF file back into my Web Application?
Is there any kind of JavaScript API I can use?
There is much overlap between PDF web editing browsers and Browser editing PDFs
the data is pulled down locally and the binary application edits the data however for a PDF, that then requires a local save as a new combined PDF. here we can see a visual reminder.
In Firefox or Chrome there are slight differences but the core need is to resave the PDF as a clients local file.
Chrome has inking
And Firefox uses a slightly different overlay but again the conjoined local data must be first saved as a new PDF.
either by print
or the top right Save (again) AS
Thus to achieve your goal you need to ask the annotator user to upload their masterpiece. However you cannot easily do that in the sandboxed page (with work frame) it needs to be after a user signal such as press button here to upload where-ever IF you were able or bothered to save as a new pdf.
I have a query. Actually, I am using an acrobat 9 pro to create editable pdf and also have a submit button in pdf itself to submit a form to a backend server. My main concern is to send pdf data to the backend server for further processing. I am using this.hostContainer.postMessage(msg) to communicate between embedded pdf and the browser. The major problem here is this.hostContainer is always undefined in pdf scripting.
Also, I have been searching for this very long time and I could not find any solution though.
Some forums even say that Acrobat 9 pro have a problem with hostContainer.
Looking forward to your help. Thanks
The HostContainer Object is only available when the PDF is being displayed in IE now, not Edge or any other modern browser. It's also not available at all on macOS or mobile. I suggest not bothering with it at all because you don't actually need to embed the PDF in a browser in order to submit the form data to a server. You just need the submit URL to be fully qualified and the submit button will work.
With the latest Adobe PDF smart forms, following are my questions:
1) Could the PDF form itself detect or be aware of what client software itself is opened with?
2) When a PDF form is opened inside a browser plugin, could the script on the form read from browser cookies? and also could the script on the form write into browser cookies?
Thanks for the info.
"latest smart forms"… this has been done for the last 15 years…
To 1): The first distinction is to make whether the PDF viewer used understands (Acrobat) JavaScript.
If not, your smart form will remain dumb, and there is nothing you can change (if the viewer allows submitting data, you could do a server-side data processing and form filling and return the filled PDF to the client).
If the PDF viewer understands (Acrobat) JavaScript, you have the possibility to test for the kind of viewer, its version, as well whether it is external (which means whether you view the form under a web browser). See the Acrobat JavaScript documentation (which is part of the Acrobat SDK, downloadable from the Adobe website).
To 2): The answer is simple: no. This is not allowed (and implemented) for security reasons.
Hope this can help.
Max Wyss.
I hava a web browser control in my silverlight application to display pdf documents.
The problem is the content does not get refreshed even after changing the source of the web browser control.
The first pdf file that gets load is shown in place of all the other pdf links.
The problem is weird since everything works perfectly fine with Adobe Reader 7 and i face this refresh issue with Adobe Reader 8 & 9.
I dont think its anything to do with webbrowser control because html pages gets refreshed without any problem
Looking forward for any help
Try this:
webBrowserCtrl.Document.InvokeScript("window.location.reload()");
Although it would be nice to not use PDF, we are using a legacy system that only generates PDF forms.
I am working with some PDF forms that embed JavaScript to submit data back to a server. The form works when viewed and filled out in the browser.
Unfortunately, our users like to download the forms to their computer, fill them out completely, and only then get an error from Acrobat Reader that it cannot submit the form unless it is loaded in a browser.
How can I make the JavaScript form submission work outside of the web browser, prevent the users from downloading the form, or have the form warn them it won't work before they fill it out?
My knowledge of PDF is probably at least one version of Acrobat behind the curve, but I think the short answer to your question is "You can't".
From a bigger picture point of view: the use of PDF as a data entry user interface is a path of much pain and suffering.
If your objective is to provide a picture-perfect UI available over the web, look at solutions like Blueprint CSS.
If your objective is to provide a 'rich' user experience, look at JQuery.
If your objective is to save yourself the work of replicating an existing document as a web form, then you have not yet learned how much real work it takes to use PDF as a data-entry mechanism.