When styling a website, one of the main techniques is to match the CSS colour codes to the colours in the images to blend sections together seamlessly. But on a couple of sites recently I have found that the sites looked perfect in IE and Firefox, but there were mismatches when viewed on Safari on my Mac.
Investigating further, I found that if I changed the Monitor Colour Profile for my Mac from the default (which was the one for my monitor type) to Generic sRGB, miraculously the website fixed itself! However, that was of limited use, as I could hardly put a note on the website “If you want this site to look right on your Mac, please change your colour profile to sRGB”!
Initially, my problem was with PNGs, and Professor Google rapidly led me to The Sad Story of PNG Gamma Correction, and through that to Browser Gamma-Consistency Test and CSS/PNG Gamma Consistency Test Results. However, all these articles are (a) old, and only consider out-of-date browsers and (b) offer no simple solutions for the web developer.
Even when I had solved the PNG problem, I then found a similar problem with JPEG files! I found a good description at Color Rendering Difference: Firefox vs. Safari, and it also led me to the Browser ICC Profile Check which tests out browsers support for colour profiles. Turns out Safari 3 (both Win and Mac) fully support ICC profiles. And none of the others - Firefox 3, IE 8, Chrome 1 - have any ICC profile support. So, the reason that Safari looks ‘wrong’ is that is implements a feature that none of the other browsers have. (Note: I understand that Firefox 3 does support profiles, but it is turned off by default).
The problem is that colour and gamma profiles were designed to allow images to be displayed in the same colours on different systems - which is what photographers and other image content producers want. However it is absolutely not what a web designer wants. What a web designer wants is that any transformation applied to CSS/HTML colour codes is applied identically to the images used in the design. We don’t actually care (that much) about the precise shade that is displayed, just as long as all elements are the same shade.
Thus images used as part of a web design (as opposed to content) need to be stripped of any embedded colour profile or gamma information.
Both PNG and JPEG files: Remove the ICC Colour Profile from the image when you save it using your image editor. Note that Photoshop automatically adds a standard RGB ICC Profile when you use the ‘Save for Web’ option. This is not what you want if you want things to work consistently in Safari. I tried to use The Gimp to strip colour profiles, and could not find a way to do it, even with the Separate/Separate+ plugins.
PNG files only: Additionally strip both the sRGB and gAMA chunks from the file. The tool I used to do this for OS X was ImageOptim enabling just PNGCrush optimisation and setting to remove sRGB and gAMA chunks. gAMA chunk removal alone did not work. Note - running this multiple times on the same file is bad - it generated a file that completely corrupted rendering of the whole web page on several browsers, one of which could only be fixed by a restart!
Note: I have not delved deep into the complexities of colour management, and do not pretend to understand some of the niceties. Frankly, I just want a solution that works on contemporary browsers and OSes. If there are situations or details that I have missed or where this does not work, then please use the contact form at http://www.jiffle.net/contact to update me.
I have encountered a recurring problem with Eclipse 3.4. When performing an update of application components it fails during the download, and in the error it details “No Repository Found” for one or more (frequently a large number) of eclipse update site URLs.
I originally found the workaround solution several months ago, in the Eclipse bug tracker, and each time recurs I have to find it again (yes - a bookmark would be useful!) but, as it does not seem to be indexed by Google, each time it takes a lot of searching to (re)locate it. Hence I reference it here, primarily for my own benefit:
The solution is to be found in a comment by Lari Hotari to the ‘Lost Artifact Repositories’ bug 236437:
Here's a workaround:
1) Export the update site listing to bookmarks.xml file
(Software Updates->Manage sites->Export)
2) Stop eclipse
3) Remove configuration/.settings/org.eclipse.equinox.p2.*.prefs files
4) Start eclipse
5) Import the bookmarks.xml file (Software Updates->Manage sites->Import)
that was exported in step 1
Note: This has worked every time that I have encountered the problem, but I have seem other causes of the error, including an issue with HTTP proxies.
Additionally, I noticed another issue last night, that, after applying the fix to a rogue Ganymede installation, the AJDT Tools continued to fail with the same error. Comparing the update site list with a working system I found that the update URL that worked ended in a trailing ‘/’, unlike that of the failing system.
Removing the problem update site and adding it back in, this time with the trailing slash, fixed the issue, but whether that was due was the addition of the slash or merely the act of removing/replacing the entry, I don’t know.