[Openicc] Funding for CPD from the Color Management side?

[Chris Murphy]

I think the primary interest for printing with Google is probably going to be cloud based, in any event. User emails or texts an image to an IP, it goes into the cloud, finds the printer wherever it is, and prints. I do not know that it would be a CUPS based solution. Any solution should of course include CUPS, I just don't know that is infrastructure you'd see used on mobile.

And yeah there are some competing details on ZeroConf that make it not exactly automatically zero configuration across platforms. However I have a Fedora 14 machine with Avahi announcing AFP, VNC, ssh and hostname.local resolution and it works flawlessly between Mac OS wired or wireless. And I use built-in tools on Mac OS. I don't see why it wouldn't with CUPS in that case, since it's just about announcing a service, so it's probably an Avahi configuration issue is all. Gotta dig into that /etc/avahi/services folder and make sure you have a *.services file for each service you want announced.

And also recently a commercial product I use regularly uses it to announce printer queues: server runs on Mac OS, Windows, Linux. And clients on Mac OS, Windows, Linux. They all appear to see each other.

Chris Murphy


On Feb 10, 2011, at 5:32 PM, edmund ronald wrote:

> I think one problem with mobile at the moment is that Bonjour/Avahi
> seems to have issues, which means that CUPS on one machine eg - mobile
> Android won't find CUPS on another eg. desktop via Wifi.
> 
> Edmund
> 
> On Fri, Feb 11, 2011 at 1:27 AM, Chris Murphy <lists at colorremedies.com> wrote:
>> 
>> 
>> On Feb 10, 2011, at 3:52 PM, Till Kamppeter wrote:
>> 
>>> Hi,
>>> 
>>> in the last days there was a lot of discussion with Color Management and printing under Linux. For controlling the CM process and preparing the PDF generated by the application for being sent to CUPS it was always talked about the Common Printing Dialog (CPD). Unfortunately, the development of the dialog is progressing only very slowly, as we do not find volunteers working on it nor enough funds to pay people to complete it.
>>> 
>>> Now I would like to know whether on the side of the color managament experts there are contacts to potential sponsors. Is the color management work for Linux somehow sponsored? Would there be possibilities to sponsor additional, color-management-related projects?
>> 
>> It seems like every graphics and photo oriented application developer should be willing to contribute some effort. Such functionality improves the consistency between applications and means, ultimately, less work they have to do on their own to get good and consistent color. I think once some workflow candidates are presented, it would be possible to get them together and see about commitments, because I think otherwise they are unsure of what the scope of such a project is.
>> 
>> As for money, pure speculation on my part. But when I think of "where the money is" these days, it's not really in color management per se. At least on Mac OS X and Windows, ICC based color management would have almost certainly died a quick cold death had it not been for Adobe's support of the ICC profile format. So that's the sort of strong arm that has been required in the past. That may not be indicative of the future, or what it means for open source. But with open source we're looking at two competing issues: fragmented money options, and fragmented development. Adobe had consolidation on both, as they pretty much said "yes we accept the ICC spec and here is our workflow" and that's it. You either like it or you don't. Whereas with open source getting a consensus can be challenging.
>> 
>> While not much printing is happening with mobile right now, Apple has just enabled this with some printers from iPads (maybe also iPhones, not sure). And more will come. HP also has a cloud based printing system for some of their Palm products. I haven't used it. Those are of course closed systems. However, it might indicate a direction for Google to become interested in printing capability in Android and Chrome OS, and they have cloud printing. There are certainly some rational incentives that could be applicable to Google and Android and Chrome OS's, but I see no indication that color is on their radar screen. So perhaps we need a way to get it on their radar screen, while also solving this problem in a way that it would have high reusability and compatibility (at least architecturally) with desktop Linux systems. I do think there is an overlap of incentives and interests here, even if they aren't exactly the same platform or target market.
>> 
>> The spread of "color critical" came largely from the advertising industry. Coke red is *THIS* color, not that color. Google is in advertising. I am very curious if they have a different philosophy when it comes to color in advertising and branding than history has dictated for companies for the past few decades.
>> 
>> Closer to home in print advertising and photography, the markets that made desktop color management happen originally - not a lot of money, not alot of Linux based products that they use either. If Adobe had apps on Linux, we'd probably get support. X-Rite, who make measuring devices, don't make drivers for Linux and actually have reduced driver support on Mac and Windows for some of their not too old measuring devices to focus on a few remaining ones. So I don't think they're a source for much support. Apple and Microsoft probably can be counted out for obvious reasons.
>> 
>> The growth market and the money are in mobile. I know most of us, including myself, are not in mobile, except probably as customers. But they have these same issues, whether they're really aware of it or not.
>> 
>> Chris Murphy
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc