One of the best parts of working at Red Hat is that you are encouraged to do things properly, even if they take a long time. I guess the logic is that if you’re going to be supporting the code in RHEL for years and years, then it pays to do it the right way, and not use some evil hack that’s going to break for a customer at some inopportune time.
As some of you might know, I’ve been hacking on colord for a few months (at the same time as PackageKit, upower and GNOME3!) and am now starting to get some upstream progress. To fix color management when printing, we really need to integrate with quite a few layers. This afternoon I rewrote pstoraster and pdftoraster into gstoraster, and added the required hooks to get the ICC profile from colord. I’ve still got to do the same for foomatic-rip, and then that’s the “query” side of the problem finished.
The next part, is to finish the work done by Tim Waugh, so that CUPS registers devices and embedded profiles with colord. With all the patches in place, it basically means that making a printer color managed becomes trivial.
Thanks go to Till Kamppeter for reviewing the different iterations of the ghostscript filter code patch, and initially pointing me in the right direction. Now I’ll brave CUPS upstream and try to get the other patch accepted there.
This is probably all a bit late for GNOME 3 and Fedora 15, but you can be sure that GNOME 3.2 and Fedora 16 will look consistently beautiful across all different types of devices. If you are feeling brave and want to try it out, try the “icc” branch of cups, the “colord” branch of gnome-color-manager, and the recently released colord 0.1.3.
Amazing! keep up the good work. It seems like we are getting low-level stuff engineered now – done right!
I’m pretty excited about this as well, great you are working on colour management! One question I have is if and how this will work together with applications which have been implementing colour management on their own like Inkscape or the GIMP. Will the settings from g-c-m interfere with the ones from the application? If there are different settings in e.g. GIMP and g-c-m, what happens?
If GIMP is sending PDF output with assigned color profiles, then it just works, even if you’re using some random FOGRA profile. If GIMP is assuming it’s sending raw data to the printer, then it should still work as long as the data is tagged as such as if the source profile == output profile then no changes should be made. If GIMP is not tagging the PDF, then all bets are off, and GIMP needs to be fixed.
> This afternoon I rewrote pstoraster and pdftoraster into gstoraster
Isn’t pdftoraster currently using poppler, not ghostscript?
Nope, at least upstream and in Fedora it’s using gs.
Alright, then this was a Debian-specific change, see
sorry, see
http://packages.debian.org/changelogs/pool/main/c/cups/cups_1.4.6-1/changelog#versionversion1.4.5-3
Just awesome!