Safari URL to PDF-page workaround? - ios

I'm trying to link from an URL to a specific page within a PDF document being viewed using the Preview.app built in Safari (using iOS on iPad2).
I know that Sarafi does not support (hopefully in the near future) the PDF parameters like for example:
www.mywebsite.com/information.pdf#page17
or
www.mywebsite.com/information.pdf#page=17
Which should result in the PDF being viewed on page 17 when opened.
But as we know Safari opens it at the first page instead.
However!
When I am displaying the PDF in Safari and I change the pagenumber (in the URL bar) into a different pagenumber, IT WORKS.
It jumps to the correct page, and I'm changing it again and again and it works flawlessly.
So I figured, alright maybe it's because the PDF needs to be loaded the first time viewing, so I preloaded the PDF in cache, but no succes.
How can I get it to work, so that it goes to the correct page when opening the PDF?
Is there a script for changing the page number after loading or is there a different solution?
You can find the PDF I'm talking about here:
http://www.michaelmaasdam.nl/mobile/new/pagina/begroting/begroting2012.pdf?page=14

Is this link being shown from a native app?
If so, you could opt to use QuickLook instead and you may have a little more control over this kind of thing from within that.

Related

Webpack url-loader PDF data URI link for Vue site stops working in iOS 14

I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.

Automatically Printing Page, then directing to next page

I am updating an old application, and have been asked to change the old Print routine (which just invoked the print command via javascript, and printed out the html), to one that prints out a pdf (the theory being that we then have more control of the pdf / how it looks etc across all printers.)
Using the Rotativa library, I can generate my pdf's, either on the fly or to a file.
After doing some reading, it appears impossible to stream a pdf from memory, and it has to be created as a file first, sent to the browser, and then deleted.)
the last line of my controller is;
return File(#"D:\Development\Source\Workspaces\ConsumerCreditLicenseSystem\Code\ConsumerCreditSystem\CCLSystem\_Idd\1.pdf", "application/pdf");
What I am strugglign with is getting that page to invoke the Print Dialog. If I send it to a new view with javascript to do this, then I am back to square one as the page is html not my pdf. Is there any way I can mark that my pdf is for printing, or combine it with some html so I can have the old faithful of
window.print();
in the document?
A PDF is not a webpage; it's a binary. When you send the PDF as a response to the user, you have no control over what happens on their end. If their browser is capable of viewing a PDF in place, it will display it; otherwise, it will prompt the user to download it. Either way, it will be up to the user whether they want to print it or not, and it will also be up to them to go back or whatever. You cannot redirect the user automatically at this point.
A slightly better option would be to redirect the user to another page, with a link to a view that will send the PDF down to them. Then, you can do things like force the PDF to download (so it's not rendered inside the same tab/window, effectively taking the user away from your site), or force the link to open in a new tab or window. However, you still will not be able to prompt the user to print.

How to export interactive PDF for iOs?

I have an interactive PDF, a catalog, where you have to click on a image to go to a specific page. All images are converted in buttons with the option "Go to destination". On Windows and Mac it works perfectly. But on iPad all the links, all the images, are not showing.
I've already read on many forums about this common problem between iOs and interactive PDF's. But I have some old PDF's, with the same principle, and those are working great on iPad. The images are showed, the links works...
That's why I'm wondering if it's not my fault or maybe I export the PDF in a wrong way.
The links to the PDF's.
m.hconline.eu/Baby%20Catalogue.pdf
m.hconline.eu/LA Catalog 2013.pdf
"Buttons" are not compatible with most pdf readers (except Acrobat reader and a few others). Such buttons are not recognized on the standard pdf reader on the iPad. I have checked the old file on the iPad, it does not work as well.
What you need to do is to use regular pdf links instead of buttons. In order to do so, you can use Acrobat Pro, delete your buttons, and create new links using the chain icon. You can specify the area of the link, so the user experience will be the same.
This is an old issue, but I did find more information regarding this. (I'd add a comment to the accepted answer, but alas, i do not have 50 points.)
According to George Johnson, "The problem with InDesign is in using the Go To Next/Previous Page options in InDesign[buttons], it creates an Execute a Menu Item action when exported to PDF, and since Reader for iOS doesn’t have menu items or interprets such actions otherwise, they are just ignored." - https://forums.adobe.com/thread/1142056?tstart=0
As for work arounds, I found a tutorial by Steve Werner, outlining the method of changing your work flow around, and adding your buttons in Adobe Acrobat instead, as kind of a post production linking process. - http://indesignsecrets.com/navigation-button-tricks-for-interactive-pdf-on-an-ipad.php

Embedded Youtube videos not appearing in infowindows

I am attempting to embed Youtube videos into some of the infowindows in the following KML file:
http://www.jonangfoundation.org/files/newdef.kml .
The videos show up fine on Google Earth and KML Builder, but on this page they do not show up at all:
http://www.jonangfoundation.org/taktentest
Anyone know what could be keeping them from showing up?
Unfortunately your 'test' page does not load - Page Not Found error.
However, I think you need to set the correct MIME type for .kml files. Your newdef.kml is presented in my browser window as XML rather than downloaded as a .kml file. That might be your problem, it is hard to tell with nothing else to go on. check out this link for details about setting the right MIME
https://developers.google.com/kml/documentation/kml_tut#kml_server
Edit: I am not sure what is going on. Your KML code looks okay to me, and I see you have tried a few different approaches, none of which appear to work. I suggest you visit this SO question, as it's answer is something you could do to make it work.
Basically, you override the default behaviour when a placemark gets clicked, and allow iframes and javascript to be used in the balloon. It is the original way of getting around your problem (however I thought it was fixed in recent version of the plug-in. Maybe not?)
I believe your content is being scrubbed. See link for description and possible work around.
https://developers.google.com/earth/documentation/balloons#scrubbing

What is the best way to manipulate an existing PDF-Document under iOS?

I need to individualize documents within an iOS-App. I could provide the origin-documents as DOCX, PDF, PPT etc. The output-format has to be PDF.
My minimun requirement is to fill some text-fields. Nice to have would be to replace an image, too.
I´m quite used to generate PDFs programmatically using UIGraphicsBeginPDFContextToFile etc. But in my current case I don´t want to create the whole document programmatically, I just want to replace some content.
Any hints / tipps?
Thank you in advance.
DOCX is a zip - format file so you can process the contents programmatically and the reconstruct the zip file. PPT is a binary format though newer versions of PowerPoint might also construct zip-oriented versions that you can programmatically process. You mentioned though that you need don't want to programmatically process these documents - which I would probably also do only as a last resort.
For your DOCX origin/source documents (or doc,odt,rtf but not ppt/pdf) you could use Docmosis cloud services if your app can have the external dependency. You would upload your DOCX origin documents with placeholders for text-fields or images as a one-off/occasional task. Your iOS app then calls Docmosis sending instructions and data to create the output PDF and either stream it back to the app or email/store it or both.
The upside is it takes all the load and coding away from the iOS application (there is an SDK). The downside is it is an external depdendency. Please note I work for the company the created Docmosis.
Hope that helps.
Why not just load a page in a webView modal that points to a URL of a page you create? The main parts of the page would be static, and then the fields you need to customize would be populated via Javascript or PHP.
For example, we have a contact form in our app that gives you an option to view the details of your completed form after you submit. When the user clicks on the button to view the Contact Confirmation, it loads example.com/confirmation.php in a modal view within the iOS App.
On the confirmation.php page (on the web), I use PHP to pull in $_GET variables from the URL parameters which then populates the page with my static content, and their customized information that they entered into the form.

Resources