When printing with (full) color management enabled (gfx.color_management.mode=1) the monitor icc profile is used. It shouldn't be used. Step to reproduce it: 1 set full color management enabled (gfx.color_management.mode=1 in about:config) 2 install a bogus profile that shows clearly when color management is used, such as this LG monitor one (from bug 450923) https://bugzilla.mozilla.org/attachment.cgi?id=344154 (save it, right-control click, choose install from the menu, then go to control panel, display, advanced, color management tab, add it as default profile) 3 restart firefox 4 load whatever url that should have white background (such as google.com) and this icc profile should display it yellowish. 5 print that page. Expected result: white background. Actual result: yellowish background.

Mmm.. Not sure witch bug this should block. Anyway adding to bug 455056 as this happens also with images with embedded profile and gfx.color_management.mode=2 (even if a bit harder to see than a color change of a white background). Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081125 Minefield/3.1b2pre

I'm not very familiar with the mechanics of printing at all - hopefully vlad can weigh in on that. In general though, simply disabling cms for printing seems incorrect. In theory we can be getting input images that are in a wide variety of color spaces, so we should be doing something so that when we print everything is in the same color space. It may be that we should still do color management but convert everything to the printer's color space rather than the monitor's, though I'm not sure what that really means. Vlad, Chris - any insight?

I agree that the display profile should not be used as an intermediate space when it comes to printing. I think the best Firefox can do is to normalize all content to sRGB, and pass that onto the operating system, tagging it as sRGB. Then it's up to the OS and driver to figure out what to do.

Vlad - how feasible is Chris' proposal given the current gfx printing architecture?

Not very; we'd want need to do a bunch of work to have layout communicate down to gfx that we're in the middle of printing. Might be something for dholbert to look into post 3.1.

On win32 we should be able to use GetICMProfile() to get the printer's profile. I believe we'll need to correct into that space. On OS X we could convert the images to sRGB, set the colorspace for the surface to sRGB and quartz should just do the write thing. Alternatively, we could just set the colorspace for the surface to actual colorspace of the image and that should work too. I'm not sure what the story is like on linux.

Linux: CUPS has some OS/X derived support for color management already in place. The difference is that OS/X has some proprietary *toraster filters that are color management aware and these are not available for other *nix platforms. This is currently being worked on and it is fairly likely that there will be development versions of CUPS with at least an open source pdf2raster filter that is color management aware by late this year. This might lead some to think - OK lets just "convert the images to sRGB, set the colorspace for the surface to sRGB" and it should work just like we think it will work on OS/X. But I have some concerns that the proposed OS/X approach is incorrect. Since OS/X is based on the PDF format and CUPS on non-OS/X platforms (IE. Linux) is in the process of converting to a PDF based work flow I think a better approach is to pass a PDF to the printing back where all of the objects are in the PDF are in their native color space and have the correct profile tags and just let the back end sort it out. This will work fully now for OS/X and mostly on other CUPS systems (some conversions will not be optimal until GhostScript has full color management capabilities for PDF files) and when the new color management aware pdf2raster filter is in place it will work fully on any *nix machine. In other words if you do OS/X correctly then at some point other CUPS based system will also just work the same way.

(In reply to comment #7) This is much like a PDF/X-3 or PDF/X-4 workflow, which is something I've advocated since the very early days of OS X. And while it works in theory, we have lots of problems with 3rd party print drivers, which simply assume sRGB anyway by default. And then also Windows XP which doesn't have the backend sophistication you mention. XPS on Vista and higher has behaviors not dissimilar to PDF/X-3 when it comes to dealing with mixed color space content. So if Vista or higher can be considered to be the mimimum supported OS, in the time frame under consideration, then perhaps there would be a reasonable amount of parity among the platforms to avoid an excessive amount of platform specific code. It is frustrating that the print driver vendors all insist on using proprietary, black-box color management that works on simplistic assumptions, by default instead of the OS's core imaging technologies when it comes to color.

This is an issue. I have been working with the Open Printing folks on color management since early this year and one of the most difficult people to work with on this subject is someone who works for a print vendor (I will not name names). He insists that the only way for things to work for "his" devices is if he gets everything in sRGB and he insists that the user apps have to send sRGB and nothing else to CUPS. My reply is to setup the CUPS PPD files for his devices with a line like: *cupsICCProfile RGB../sRGB Profile: "sRGB.icc" And restrict his device so that users can only select an RGB print mode. Then his devices will always get sRGB input because the core CUPS facilities will just take care of it for him (assuming that the new CM aware *2raster filters are in place). But he does not seem to get the fact that using these powerful facilities will actually work or that it could be that simple. From my experience most of this comes from printer vendors rather than 3rd party driver developers but it is a mixed bag. A good third party example is that all of the newer GutenPrint PPD files are correctly setup on OS/X with generic RGB, CMYK and Gray printer profiles. One of the problems is that they have the same setup on other *nix systems and this is not correct for these systems (IE. the profiles don't exist and the directories referenced do not exist). I expect that this will be fixed by the time the new CM aware pdf2raster filter is available in CUPS. But you are right that there are a significant number of those involved in writing printer drivers for *nix systems that are clueless about color management. The GutenPrint folks are among those who are working to understand this and they have made lots of progress. Things are getting better in this regard but it will take a while to get past this issue with all of the printer driver vendors. Of course we can say the same thing about firefox 3.5 since they stopped using the very powerful LCMS engine to handle color management and substituted their own reduced functionality CM engine. Users, including myself, are not happy about this since CM is now basically broken in firefox 3.5 when it was working in a mostly correct fashion in 3.0 and 3.1.

When my coworker who has an Adobe RGB monitor tries to print, everything is washed out. This is crazy since she is our graphics designer!! I have enabled full colour management (mode 1) in her Firefox so that web pages aren't excessively vibrant on-screen. Turning it off is not an option because, again, graphics design.

With P3 gamut being the Next Big Thing™, lots of people are going to start seeing washed out printed documents. This really should be looked at.