I have a set of PDF files which have a few validations embedded into it using JavaScript. Validations like a date or time format, total getting calculated from various fields etc.
I have tested these PDF and they work good on Mac Chrome browser, on Windows Chrome browser, Windows Adobe Reader and on iPad Adobe Reader. However, same does not work on iPad when using Apple PDFKit to render the PDF in a PDFView. It does not validate, format any of the fields or give a popup validation error how it does in the iPad Adobe Reader App. For testing purpose, I am keeping this pdf in the applications and accessing it directly from there.
Is it possible to get the same functionality as the iPad Adobe Reader App where we get validation errors/popup when something is incorrect?
I found that the built in PDF viewer in iOS is very limited, it can't run JavaScript, probably for security purposes.
For a recent project we used Foxit's PDF SDK for iOS, I believe it has its own JS engine so it will run all of the scripts in your PDF.
Related
I have a rails app that generates a pdf for a given html partial. In the partial I have a number of links that have a target of _blank, however in the generated PDF the target looks like it is being ignored.
I just want the pdf to open links in a new tab/window.
A collaborators from PDFKIT said
"This sounds like a problem with wkhtmltopdf (which is what renders the pdf from the html). (Pdfkit just wires up everything between ruby/rails and that binary.)"
Any help would be appreciated.
Regards,
Sean Hubers Answer:
PDFs are not marked up with HTML. How a link click is handled in a PDF
depends on the PDF viewer you are using. Modern browsers with built-in
PDF viewers may navigate to the page within the same frame as the PDF
view and that is not something that can be controlled with an HTML
element attribute. What happens if your link is clicked when the PDF
is being viewed in Adobe Acrobat or Mac Preview? You're at the whim of
the software and operating system. Sorry to bear the bad news but this
is the reality of the PDF format.
I have looked around the web and have found that appending #page=?? to the end of a PDF link will automatically take the visitor to that specific page in the PDF file.
I was wondering if this is still best practice as it doesn't seem to be working for me (Chrome on Windows 7). Also, all the articles I have found so far date back to 2006-2008, have things changed recently?
This is still valid code but it may require that some version of Acrobat (Reader, Pro, etc) be installed as a plugin on the browser in order for it to work as expected. Since multiple commonly-used browsers now have a built-in reader (Chrome, Safari for iOS are the big two that come to mind) support for direct page linking is somewhat spotty now. You can still do it...the worst case scenario is that the PDF just opens to the first page for those users but I would advise to just leave off the direct page link. If the page is that important, extract it to a separate PDF and link to that.
I would like to develop an interactive XFA form in LiveCycle Designer ES -2 which will support Windows as well as i-Pad. But the problem is when I open an XFA form it does not show the form rather it shows the form can not be shown(If the form has scripts within it).It only shows simple PDF documents in read only format.It also does not show the button in Acroforms.There is no interactivity related with the form.I would like to know is there any way to show the interactive PDf forms?
There is also another solution from SPZAP designed for Microsoft SharePoint and supporting XFA forms in PDFs and in some way in HTML5 compliant browsers. It has a form designer that runs in a browser (html5) and two kinds of runtime that are SharePoint integrated and are displaying PDF either in Adobe Acrobat Reader (probably Foxit in future) or converted as html5 structure (with some limitations in latter case). http://www.pdfsharepoint.com
LiveCycle Mobile ES4.0 will be able to render your forms. The look will be similar to HTML rendering.
http://www.adobe.com/products/livecycle/mobile/
The built-in pdf reader doesn't support dynamic PDF forms, Adobe doesn't have an iOS client and iPad doesn't support flash (natively).
Your only option is to render the form as HTML using LiveCycle Forms ES (server module).
You cannot render an interactive form in iPad as pdf. Reason being Apple doesn't allow any application (except web browser) to run any kind of scripts inside it (In this case Acrobat application, trying to run Javascript).
But you can render it as HTML which can be rendered in a browser and has some strip out functionality than the pdf version but its worth to try.
I currently use a PDF-to-Flash to allow for users to flip thru pages of uploaded PDFs. However, with so many using iPhones/iPads I would like to switch this to a solution which works with any browser.
The site is developed in Ruby on Rails and I have looked into using pdf-toolkit and rmagick to convert the PDFs to images but it's not enough since I want the pages to scale with the browser window - SVG is not an option since I need for it to work w/ IE6 ;)
Any ideas?
Thx,
G
Why don't you use http://docs.google.com/viewer ?
http://googlesystem.blogspot.com/2009/09/embeddable-google-document-viewer.html
It's really simple, and it isn't Flash (can serve iPhone users too :D). Just add this to the view:
<iframe src="http://docs.google.com/viewer?url=#{YOUR_PDF_URL}&embedded=true"
style="width:600px; height:500px;" frameborder="0"></iframe>
Another option is a digital publishing platform like the one from Zmags. It converts a PDF to Flash, but when viewed on mobile devices it transforms into a swipeable version. Loads fast too.
When using Adobe Acrobat Standard 9.1.2 and its built in Web site grabber, I end up with the following error in the PDF, “Rendered with sIFR 3, revision 436."
Is there a way to force Acrobat to render the plain text instead of the flash test? Or a way to make sIFR compatible with the Acrobat site grabber?
Note the site displays fine in Firefox 3.5 and IE7. Other forum posts have indicated this sort of error in a browser indicates a mismatch in sIFR and javascript versions.
I'm unfamiliar with the way Acrobat captures web pages, but it sounds like it's trying to capture (or embed, who knows) the Flash movie directly, and failing. You might be able to detect Acrobat through a user agent string, and disable sIFR if it's looking at the page, but otherwise I'd consider this an Acrobat issue.