While using PrestaShop 1.6 even if you set it to store all images as png, and they in fact are, the PS always adds .jpg extension instead of the correct one (.png), however it works anyway (at least in Chrome).
Does all common browsers treat images according to their file header? Or is there some major browser that I need to consider and repair core(which I would really like to avoid) to use correct extensions?
Thanks
Browsers don't care about the file extension at all, but they do care about the content type in the HTTP header. The server generally uses the file extension to determine what MIME type to put in the HTTP header, so it may end up sending the images with the wrong MIME type.
However, once the browser has determined that the MIME type is an image, they don't tend to be picky about the image format. There may be some special cases, but both PNG and JPEG files have an easily recognisable signature in the beginning of the file, so the browser can easily see what the format actually is.
Related
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.
I am looking for a site for somebody, and fixing errors as I find them.
There is no Favicon.. that is ok, I can fix that.
My question is, do browsers (or certain browsers, Chrome in this case) request favicon.ico as soon as they load a site.. or maybe on check that there is no alternative icon path mentioned in the source.. irrespective of whether "favicon.ico" is actually mentioned in the page source?
That was the original behaviour, yes. /favicon.ico was an implicitly present file which (some) browsers would check for. Only later did that actually morph into a proper standard with <meta> tags, arbitrary file names and image formats other than .ico.
I'm making a Chrome App and need to package images with the app, so they will not be served by an external server. I'm attempting to load local svg files, but in Chrome (Version 40.0.2214.111 m) in all my efforts to display the svgs keep getting the error Resource interpreted as Image but transferred with MIME type application/svg
Ideally I am trying to find a way to load local svgs in <img> tags. Is there a way to do this locally? I understand that svgs that are served contain proper headers telling Chrome how to display svgs in img tags, but I cannot get this to work with locally stored svgs.
Please don't suggest using pngs unless you know that is the only solution. I must be missing something obvious.
This problem I had with the fonts, the way in which I decided was to use:
src: url(data:application/x-font-woff; base64,/*..file data...*/)
In your case, try a method of using SVG files in local mode
When clicking a PDF link in Firefox and Chrome, the file will sometimes be opened for in-browser viewing and sometimes prompt a "Save as" dialog.
If I wanted to force the link to always prompt a download I could use the download HTML5 attribute.
However, I want to do the opposite. I.e., force the links to always be viewed in the browser.
Sort of an inverse download attribute. Is there such a thing? :)
I'd prefer to not modify response headers when serving PDF documents - I want to be able to specify in markup what the browser behavior should be.
Thanks!
You can achieve that by setting the appropriate header (for instance, in case of PDF, the header will be Content-type: application/pdf;
With this header, the browser will know the mime-type of the file and display it if it is compatible with it.
Here you can see the headers for a PDF.
As a hint, what I like to do is to use some sort of controller (in case you are using a backend language) that handles the download. Hence, to download myNewProject.pdf I do
<a href='download.php?file=myNewProject.pdf&viewInBrowser=1'>Download!</a>
Then I can set the appropriate headers depending on the file type, or if I want to force download or view it in the browser...
I'm using Firefox in XP. I went to the OPTIONS under Tools and found Portable Document Format. Click on it and it will allow you to change the way PDF files are handled.
open the file in a Microsoft Word and save as html.
I have a very strange problem:
I use xsl to show an html picture where the source is defined in the xml file like this:
<pic src="..\_images\gallery\smallPictures\2009-03-11 אפריקה ושחור לבן\020.jpg" width="150" height="120" />
[the funny chars are Hebrew- ;) ]
Now comes the strange part:
When testing the file locally it works on Firefox and Safari but NOT in IE and opera. (file://c:/file.xml)
Next I send the file to the host throw FTP (nothing more)
Than it suddenly works with all browsers when calling the page from the host: (http://www.host/file.xml)
The question is how can the server send the xml file to my browser in a way that my browser can read, while the same browser cannot read the same file stored locally ?!
I always thought that both HTML(xml) and pictures are sent to the client which is responsible to load the page - so how come the same files works for my webhost provider and not for me?
And what makes it totally strange is that IE is not alone - Opera joins it with this strange behavior.
Any ideas?
Thanks alot
Asaf
When you open the file locally, there is no server to serve up HTTP headers. That's a big difference at least. Try examining the coding the browser thinks the page is in, when it's opened manually from disc, and when served over HTTP.
If headers are set correctly by either your script, or the server, then that is likely why.
This is most likely an encoding problem. Try to specify the encoding explicitly in the generated HTML page by including the following META element in the head of the page (assuming that your XSLT is set to generate UTF-8):
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
...
</head>
...
This tells the browser to use UTF-8 encoding when rendering the page (You can actually see the encoding used in Internet Explorer's Page -> Encoding menu).
The reason why this works when the page is served by your web server is that the web server tells the browser already what encoding the response has in one of the HTTP headers.
To get a basic understanding what encoding means I recommend you to read the following article:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets
..\_images\gallery\smallPictures\2009-03-11 אפריקה ושחור לבן\020.jpg
that's a Windows filepath and not anything like a valid valid URI. You need to:
replace the \ backslashes with /;
presumably, remove the .., if you're expecting the file to be in the root directory;
replace the spaces (and any other URL-unfriendly punctuation) with URL-encoded versions;
for compatibility with browsers that don't properly support IRI (and to avoid page encoding problems) non-ASCII characters like the Hebrew have to be UTF-8-and-URL-encoded.
You should end up with:
<img src="_images/gallery/smallPictures/2009-03-11%20020/%D7%90%D7%A4%D7%A8%D7%99%D7%A7%D7%94%20%D7%95%D7%A9%D7%97%D7%95%D7%A8%20%D7%9C%D7%91%D7%9F%10.jpg"/>
There's no practical way you can convert filepath to URI in XSLT alone. You will need some scripting language on the server, for example in Python you'd use nturl2path.pathname2url().
It's generally better to keep the file reference in URL form in the XML source.
#Asaf, I believe #Svend is right. HTTP headers will specify content type, content encoding, and other things. Encoding is likely the reason for the weird behavior. In the absence of header information specifying encoding, different browsers will guess the encoding using different methods.
Try right-clicking on the page in the browser and "Show page info". Content encoding should be different when you serve it from a server, than when it's coming straight from your hard drive, depending on your browser.