When I try to load a PDF Data URI into an iframe (eg, src="data:application/pdf;base64,...") in FireFox (18.0.2 [current release], OSX) it instead opens a download window.
For an example, check out the website JSPDF.com
The same site works fine in Aurora (20.0a2)
Is this a known issue with Firefox? Is it not conforming to the spec...?
Aurora has a built-in PDF renderer that can render PDFs inline.
Current release as of yesterday does not have that; it first appears in Firefox 19, which is about to be released.
A browser without a PDF plug-in or built-in PDF renderer will simply offer to download or open in a helper app a PDF that's loaded in a window as you're doing, which is exactly what you see.
As far as the spec goes, both behaviors are compliant. Nothing says a browser needs to support inline rendering of PDF.
You need to modify the options :
To :
I had a very similar problem with Firefox, iframes and data URIs. I resolved it by checking that there was no spaces in the data type definition. Mine was text/html, so instead of writing this:
src="data: text/html, ..."
it had to go like this:
src="data:text/html,..."
I conclude that firefox didn't understand the content type with spaces, thus considering it was a downloadable file.
This might be caused when there is no adobe reader installed. I'm not sure though. As I can't test it here as I don't have a Mac with Firefox running.
Related
I'm currently using a solution which converts a pdf file to a data URI. The data URI is then set as an iframe's source and displays the pdf on almost every major browser, I have learned that IE 11 does not like this though. After reading up on it, i realize that iframes don't support data URI's as the source (nor do any elements other than an image URI) and that I can't set a source for an element so I'm unsure how I could achieve the same with Internet Explorer.
I've tried using an embed (learned that it doesn't like data URIs either), an iFrame, initiating a download in a new tab of the file itself (to mimick viewing a it in the browser - no avail) and I'm running out of ideas but unfortunately a lot of people still use Internet Explorer so I'd like to make it compatible. Is there any way to recreate this behavior in Internet Explorer like other browsers do?
Thanks in advance :)
I ended up giving up on this for lack of time to research/test. The final solution was just as well I suppose. I ended up writing the PDF to subdirectory in the website and then setting the source ofthe iframe to the download method of the file. Tad slower than my original implementation but it works for legacy purposes. When will IE die!
I built a PDF in Illustrator, and am linking to it from a web page. It looks fine in SumatraPDF and in the Windows preview pane, but the browser renders this (just so you know, this is not how I want it to look)
Is this because I have font embedded? The only thing that I want to have happen with this is for a couple links on it to be clickable; otherwise, I'd convert it all to outlines. Is there something I need to do here that I haven't done?
EDIT: Here's a weird update about this. The browser follows the link embedded in the pdf when I click it. So it has the right data, but the wrong presentation apparently.
I'm assuming you are/were using either the Dev or Canary channel of Chrome. There was an experiment running in both channels that was causing this, which has since been reverted in Canary but is still affecting Dev 59.0.3053.X. For the more technical; this experiment enabled the PDFium code to use Skia to render paths instead of Anti-Grain Geometry and caused this font gibberish.
Here is the link to the bug report:
https://bugs.chromium.org/p/chromium/issues/detail?id=705039
UPDATE: This was fixed in the Dev Channel with update 59.0.3071.X
I have the following code in a html document:
<p>PDF sample</p>
<object data="http://www.whateverdomain.com/whatever/~/media/sample.pdf" type="application/pdf"></object>
This is working in IE, Firefox but not in Chrome. Appears a grey box in the browser with no embedded pdf. When I check on "network" tab in chrome I'm receiving a HTTP 200 response but PDF is not shown.
I tried URL encode tilde "~" symbol replacing it by %7e but still its not working on Chrome.
I don't have the possibility of changing the url which is provided by an external service.
Do you have any clue on how to solve ?
You might wish to try and use a simple iframe. At the very least I am pretty sure that works for chrome, might not work for IE though. Another alternative is using the Google Docs viewer, with that you are sure to be cross browser compatible, although some pdf's might not render perfectly. The last option you have is using something like pdf.js to render the pdf's yourself inside the browser. Gives you a lot of control and ensures that even people running computers without a pdf viewer installed (or a native pdf viewer like chrome and firefox) will be able to view the file.
I tried looking for a Chrome extension that does this, but was unsuccessful in finding one. Basically, I want to hit a web service that returns a content type header of application/rdf+xml or application/xml and have Chrome automatically display the content inline. I have the XML Tree extension which displays the XML just fine, but Chrome by default will download files unless they have a certain extension.
My question is: Is there a way to force Chrome to open certain things inline based on Content-Type returned from the server? Extension or direct support in Chrome is fine with me. If one doesn't exist, I'll investigate developing one.
Great question, one I've been trying to answer for ages. Unlike firefox, chrome, and chromium, use an external xdg mime-type query to decide what helper applications to use, but one generally doesn't want to set chrome as a generic handler for application/rdf+xml. So I was very pleased to discover the chrome extension "application/...+json|+xml as inline." Available from the web store, or at
https://github.com/andreineculau/chrome-inline-media-type
Thanks andreineculau!
When I click on an image link right now, Chrome downloads the image instead of opening it.
Even if I right-click and select Open link in new tab Chrome still downloads the image, and I have to go through the extra steps of opening the file for viewing manually.
This feels like a mime-type issue to me, but why would Chrome not recognize "image/png" as a valid mime-type for viewing? All PNG images display just fine in an HTML page.
NOTE: This only happens for PNG images.
The web server is probably serving the image using the image/x-png MIME type. Chrome does not recognise this as an image (as of August 2012 February 2013), hence offers the file as a download.
image/x-png is a legacy MIME type from the days before it got its official name, image/png, in 1996. However, when Internet Explorer uploads an image it does so using image/x-png "for backward compatibility". I believe this was the case up to IE8, and was "fixed" in IE9. If the web server does not correctly handle this (the web server should detect this non-standard MIME type and treat it as image/png), then it may serve up the client-provided MIME type to other users, including to Google Chrome. Additionally, some web sites will serve up all PNGs as image/x-png.
If you're the web developer you should detect incoming image/x-png and treat it as image-png (never serve up image/x-png).
If you're the user report it as a bug and see #kriegaex's answer for a workaround.
#Tom Clift is right, and here is my workaround for it: use Chrome extension Redirector and add a rule replacing the Content-Type header. That's it. :-)
You can use the Chrome extension Undisposition to achieve this.
When you right click on the image you need to select then 'Open image in new Tab' from the drop down and NOT 'Open link in new tab' this will then open the image in a new tab.