Technology at my disposal:
HTML, HTML5, LINQ, C#, ASP.net, Razor, jQuery, Javascript, Entity
I would like to view my MHTL file on my website. Is this possible?
I tried using IFrame but this only forced a download of the file.
Use an browser plugin or preference, such as the following:
unMHT and Mozilla Archive Format plugins for Firefox
MHTML preference in the following URL for Chrome or Opera:
chrome://flags/#save-page-as-mhtml
MHTML URIs for IE, (but registry and HTTP headers may need configuration)
Related
I am using embed tag to display pdf from a web src just like this
<embed src={'http://www.somePDF.com/file.pdf'} type="application/pdf" width={"100%"} height={400} />
the problem is that in Safari is displaying the pdf correctly but in chrome is automatically dowloaded and I cannot see it in the page, for more details i am using react.js
From Mozilla (FireFox)
Keep in mind that most modern browsers have deprecated and removed support for browser plug-ins, so relying upon <embed> is generally not wise if you want your site to be operable on the average user's browser.
For current view on the relationship by chromium see https://bugs.chromium.org/p/chromium/issues/detail?id=1257611
A pdf is application/executable binary (like docx with macros) i.e. may contain JavaScript. A secured browser should not run a pdf it should offer to ignore or download it to a sandbox for neutering.
How a PDF should be displayed in a secure browser, based on Chrome code base.
I just want to know which file types (like .png, .pdf, .txt) can be viewed in browser (like Chrome, Firefox). Because sometimes when i click on file link, instead of displaying in browser it download automatically. Why this happens ? Below is my code. Any help will be appreciated.
<script>
function openPDF(url){
var w=window.open(url, '_blank');
w.focus();
}
</script>
<a href="burger1.jpg" target='_blank'>link</a>
<div onclick="openPDF('1.pdf');">PDF 1</div>
It indeed depends on several factors:
the server response Content-Disposition header value inline (open it) vs attachment
(classic download)
the browser configuration (how to behave for various file types)
installed browser plugins
the ability of the browser to open the file
A detailed technical explanation can be found here: https://superuser.com/questions/1277819/why-does-chrome-sometimes-download-a-pdf-instead-of-opening-it
For example Firefox can open most PDF files (but generally not advanced forms, encrypted files ...),
https://support.mozilla.org/en-US/kb/view-pdf-files-firefox
https://support.google.com/chrome/answer/6213030?hl=en
https://helpx.adobe.com/lu_en/acrobat/kb/open-in-acrobat-reader-from-chrome.html
https://www.investintech.com/resources/blog/archives/3684-view-pdf-files-mozilla-firefox.html (about browser PDF reading)
Most advanced PDF features will require the user of Acrobat Reader or a special Acrobat Reader plugin.
There are two aspects to this issue.
There are addons you can add on to the browsers to allow viewing virtually anything in the browser window. In the case of PDF, for instance Firefox can't show those by default, but you can install an addon. Or, there are standalone PDF viewers that also come with such an add-on which you can activate if desired.
And when you've done that, as noticed in the comments, if the resource is marked as download, the browser will download it instead of trying to open it, no matter the file type.
Ditto if it has a http header of Content-Disposition: attachment.
So don't use that.
In normal cases, following files can be viewed in browser.
.PNG
.JPEG
.PDF
.doc
etc ...
and following files will always be download.
.zip
.exe
etc ...
But in special cases, it depends on user browser settings and preference. You can get further details from this link.
Trying to embed a pdf on my website like so:
<iframe src="filename.pdf" type='application/pdf' frameborder="0"></iframe>
The website is a rails site, and currently I'm only running it on a local server.
The problem is that the pdfs render with a toolbar on top and a sidebar with my adobe creative cloud account information, as seen in the picture below (the actual content of the pdf displays in the white box under the toolbar and to the left of the sidebar)
How can I get the pdf to render alone, without the menu and sidebar?
If you allow the browser to choose how the PDF gets rendered, you're never going to be able to create a consistent experience for your users unless you are in a controlled desktop environment.
If you are looking for a consistent experience, use pdf.js to render the PDF in the browser.
If you are in a controlled environment and all of your users have a browser/viewer combination that will let the browser show PDF using the Adobe Reader plugin (as your screen shot shows) then you can use the "open parameters" at the end of the URL to control what gets shown. See the documentation at the link below.
http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_open_parameters.pdf
That said, don't count on that solution to work for very long. Most modern browsers are not allowing the viewer plugins to function anymore and the rest are moving in that direction.
Searching more into stack, try that:
https://stackoverflow.com/a/2105095/7741129
For more detailed informations:
http://blogs.adobe.com/pdfdevjunkie/web_designers_guide
I think it's better use some kind of JS stuff just in case of cross-browser issues, like related into first link. Solutions like https://pdfobject.com/ it's helpful to get the job done. Look:
PDFObject 2.0 detects browser support for inline/embedded PDFs. (In
case you were wondering, your browser supports embedded PDFs. You
lucky dog, you!)
If you're working with dynamic HTML, such as a single-page web app,
you may need to insert PDFs on-the-fly. However, PDF embedding is not
supported by certain browsers. If you insert markup without first
checking for PDF support, you could wind up with missing content or a
broken UI.
The PDFObject utility helps you avoid these situations by detecting
support for PDF embedding in the browser; if embedding is supported,
the PDF is embedded. If embedding is NOT supported by the browser, the
PDF will NOT be embedded.
By default, PDFObject 2.0 inserts a fallback link to the PDF when the
browser does not support inline PDFs. This ensures your users always
have access to your PDF, and is designed to help you write less code.
The fallback link can be customized, or the option can be disabled if
you prefer.
PDFObject 2.0 is npm-ready. Modern web apps use npm to manage packages
and dependencies. PDFObject 2.0 is registered with Node Package
Manager (npm) and can be loaded dynamically.
PDFObject also makes it easy to specify Adobe's proprietary "PDF Open
Parameters". (Be warned these parameters are only supported by Adobe
Reader, most PDF readers will ignore the parameters, including the
built-in PDF readers in Chrome, Internet Explorer, and Safari. Read
more below.)
I wonder if there is a way to view .ps files without downloading/saving them while one using the Google chrome?
There is currently no way to view .ps (PostScript) files in Google Chrome.
I can imagine two ways to get the desired result though:
Convert the postscript file to PDF with some third-party utility and use Chrome's built-in PDF Viewer (or the PDF.js PDF Viewer Chrome extension) to display the PDF file. (this is relatively easy and can be implemented as a Chrome extension)
Implement a PostScript parser, and integrate it in PDF.js.
Specification: http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/postscript/pdfs/PLRM.pdf
Limited proof of concept: http://logand.com/sw/wps/
Feature request on PDF.js issue tracker: https://github.com/mozilla/pdf.js/issues/1594 (this is closed, but if you deliver a high-quality patch, the patch may be accepted).
I compiled GhostScript 9.26 in Web Assembly and wrote a small wrapper to allow direct display of PostScript files in Chrome. You can find it here:
https://chrome.google.com/webstore/detail/ps-wasm/ebpiondkhkldijolgmhfenknngkkjola
You may try to use another open source browser. For example, the 2018_12 up-to-date openSUSE package collection version of the
http://www.seamonkey-project.org/
opens the .ps file in an external program in 2 clicks:
click displays the ps-file as "source code"
the "source code" view has a button titled "Open in External Program..." and after clicking that button the default .ps viewer application is launched.
At the time of the writing of this comment, the SeaMonkey web browser also supports the various old-school Java applets. A page with a Java applet:
http://math.hws.edu/TMCM/java/xSortLab/
The SeaMonkey also has a WYSIWYG-HTML-Editor, which unfortunately generates the pre-HTML5 HTML, but for users with non-IT-background it can still be very helpful as a static web site based document creation tool.
Thank You for reading my comment.
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.