I'm building a web app that shows pictures. Most of the pictures were taken by smart phones and have EXIF rotation information.
I'm exposing a url which return the image blob without modification.
I've notice that when I put this url in img tag Chrome does not respect the EXIF orientation data but when I put the url in chrome address bar it show a page with the image and then it does respect the EXIF orientation.
Sorry I can't share the image, I'll try to find another example that I can share.
Has anyone notice this problem?
The reason for this behavior is that Chrome auto-rotates pictures based on EXIF data only if they are displayed directly in a browser tab as the main document.
The relevant chromium issue that tracked this implementation is the following:
https://bugs.chromium.org/p/chromium/issues/detail?id=56845
In the future, Chrome (and other browsers) will allow developers to enable auto-rotation also for images displayed via img tags with the CSS image-rotation property:
https://bugs.chromium.org/p/chromium/issues/detail?id=158753
Update: as of Chrome 81 (moved to stable on 5/13/20), this behavior is supported in both img tags and backround-image tags. https://www.chromestatus.com/feature/6313474512650240
Related
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
Can someone help me here. I have a PHP script which uploads an image and resizes it, and then an HTML page which displays the image. However, for some reason the HTML is rendering a rotated version of the image, although I can't for the life of me see why.
<div style="height:75px;width: 116px; background: url(http://viralsmods.com/pokeroulette/content/images/7.jpg);"></div>
Run the above snippet to see it in action. The image it is linked to is here: http://viralsmods.com/pokeroulette/content/images/7.jpg.
Any idea on why this could be?
The problem is related to EXIF (Exchangeable Image File Format) and the web browser
Basically, EXIF is a standard for holding file info such as which way an image should be rotated. Photos taken with (older) devices that do not use EXIF may not appear correctly in your web broswer.
The solution is to bring this file into photoshop, rotate as needed, save, then reupload for your site.
below screen shot describes my problem.. The image src is correct as the image can be seen in firebug, but I am unable to display the image in browser.
Can anybody tell what I am missing ???
Security restrictions in some browsers prevent pages hosted on HTTP from embedding images using file: URIs.
See the solution given below, and see your image path, you will understand it automatically-
I have an app that displays the same image in multiple locations and may change the src of an image.
When I point to a PNG image that I've already used before, the browser does not bother making a new request, it simply uses the PNG image that's already in the cache. However, when I point to an SVG image image that I've used before, the browser (Chrome 22) makes a new request. The server returns 304 (Not Modified), so no new image needs to be downloaded, but this still takes some extra processing.
This can be easily tested in this jsFiddle: http://jsfiddle.net/jtmuw/1/
$('button').click( function() {
$('#a').attr('src', "myImage.svg");
$('#b').attr('src', "myImage.png");
});
If you open the fiddle with Chrome (or at least Chrome v.22.0.1229.94) and you open up your network tab you will see the two images have been requested. If you then hit "reload images" several times, your network tab will show multiple requests for the SVG image but no further requests for the PNG image.
As far as I can tell, the same headers are being returned by the server, so I can't see any reason for the difference.
I am not seeing this on FF or Safari, so this may be a Chrome issue. However, I still feel like maybe there is some underlying differences in the headers that I'm missing, and it's not just that Chrome is treating SVG images weirdly.
You can perhaps force Chrome to cache the file. w3schools has a pretty good overview of this as follows: http://www.w3schools.com/html/html5_app_cache.asp
Essentially you'll want to create a manifest file (call it... "myCache.appcache" or whatever else)
CACHE MANIFEST
/path/to/svg/file.svg
and then point to this in your html file as so:
<html manifest="myCache.appcache">
This will tell Chrome that, even when you don't have internet access, this file should be cached and accessible anyway.
Include the SVG image at the top of the document.
<html>
<head>
...
</head>
<body>
<img style="display:none" src="cached.svg">
....
</body>
<html>
We're using the customer's default browser to display locally generated HTML files in a preview mode. The files are between 0.5M and 2.5M in size. These files do not progressively render in any of the top 5 Windows browsers (Chrome, FireFox, IE, Opera, and Safari). In other words, when we try to load these files, the browser window displays a blank white page until the page is fully loaded.
The HTML files we generate have no tables or script and have all CSS references in the head section of the HTML file. Our pages include about 10 unique 16x16 png images (with image height and width explicitly included on each img tag) that are referenced several hundred times. Our output validates 100% compliant with XHTML 1.0 Strict using the W3C validation service.
Any tips on how we can enable progressive rendering of LOCALLY loaded HTML files or is progressive rendering a feature that is disabled for locally loaded files?
As an alternative, I'm looking for any tips that would allow us to display a GIF busy indicator graphic while the rest of the file loads and is rendered. We tried doing this by placing a GIF image at the top of our HTML file (immediately following the open body tag) followed by a div with display:none styling that included the full content of the HTML we want rendered. Unfortunately, the GIF file does not display until the full HTML file is loaded.
Thank you,
Malcolm
I can suggest that you confirm that the content is being interpreted properly by the browser. Despite the W3C checks, things could still be handled in 'quirks mode' .. In my experience, 'xhtml-transitional' has proved to be the most likely to provide cross-browser zen. Also, confirm that major tags like 'div' and 'p' are being closed quickly. It's hard for the browser to know what to do if the whole page is always in one layer of 'div' ..
Good luck!
Tim