I have coded for every year a function with jsPDF to create a PDF from a HTML table. That works fine every time. The PDF was for saved instead open it. In Firefox had it worked. But in the last/yet time, Firefox (99) open a blob. I have no change the Firefox settings. When change the FF settings to "PDF = choose" instead "PDF = open" (default), than the PDF will saved, the save dialog pops up. The function is not for me, and also my FF settings are unimportand. The function is for the website visitors, and i can not change there FF settings.
So, all is fine and works, but the thing with the blob should not be.
My question is: How is it possible that the PDF never opened as a blob?
I use the jsPDF version 1.5.3. The newest (2.5.1) don't work by me (another problem).
Related
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.
I would like to upload the pdf of a paper on my new google site. Specifically, I want that people can click on, say, "paper_title" and can visualize the pdf and, if they want, download it.
I would like if possible a step-by-step explanation.
Thanks!
This is fairly straightforwards:
Firstly, store the PDF files on Google Drive and, set the link sharing as appropriate (e.g. anyone with link can view) so even anonymous internet users can see the file.
To make the PDF available via Google Sites you can either:
From Drive, copy the link to the file, and in new Sites insert a text box and
include the hyperlink to the PDF file in the text box.
in new Sites Insert (From Drive) and select the PDF file from the Google Drive; gives the same result as above, but with a re-sizable thumbnail picture of the PDF file instead of a link.
Exactly what happens after they click on the link is going to depend upon what browser the user is using, and what (if any) PDF viewer plugin is installed. Chrome, pretty much does what you want: it opens the PDF file in a viewer, from where you can download it.
Even if you don't store the PDF on Google Drive, what is described above should still work, as long as you have a hyperlink to the PDF file.
I am working on an Office-js add-in that uploads the body of the document as OOXML, does some processing, and then "sets" the body of the original document to the processed one from our server using insertOOXML.
The processing inserts inline images around certain blocks of text. When the add-in is tested on Mac and Windows it works flawlessly. On the iPad however, the images look correct initially but if the document is saved and reopened all of the images are changed to match the first image. If the document is first processed on Mac then sent to the iPad, this is the case as well. The images look correct at first but after saving and quitting the images all match the first image.
I have retrieved the document from the server directly and have not been able to recreate this issue, which makes me think it is related to how the document's body is set.
A little more detail on our implementation: The document is uploaded as OOXML and is treated as a docx file. I'm reasonably sure that the processing on the server is bug free because we use the same code to process docx files elsewhere without issue. To set the document, it is requested in flatOPC and set like so:
Word.run(function (context) {
var body = context.document.body;
body.insertOoxml(docXML, Word.InsertLocation.replace);
return context.sync()
});
Where docXML is the document in flatOpc format.
Is anyone else having a similar issue? Otherwise is this an issue with our code, insertOoxml, or Word on the iPad?
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.
PDF Expert is an iPhone application that enables user to fill the editable PDF and can save it. means It is editable form.
I used UIWebView to show the PDF, It showing exactly as it is, but the text field on it is un-editable.
I tried using the UIDocumentInteractionControllerto view the pdf, It showing well, but I can't edit on that file.
In safari browser of mac It supports only viewing the file, but Google Chrome supports editing of the file. and While opening the file using Preview application on mac, It allows edition to the user and can save it.
Please suggest me, How to edit and save the file in this..
Thank you...
I was after the same thing and found this to be a seemingly good solution: https://github.com/derekblair/ILPDFKit
Lets you fill in a form, access/set fields and then save out as a static copy.