[Openicc] [Per Queue] [GSOC] Making a color assignment in CUPS web interface?

[edmund ronald]

Chris, and others ...

 I think Apple as such is out of *this* discussion relating to CUPS,
because we are now talking of the forked openprinting CUPS. Please see Tim
Waugh's message
http://lists.fedoraproject.org/pipermail/devel/2012-January/161306.html

 In a way this simplifies things because we can decide about the stuff
needed for Linux by ourselves.

Edmund


On Mon, Feb 27, 2012 at 7:02 PM, Chris Murphy <lists at colorremedies.com>wrote:

>
> On Feb 27, 2012, at 3:25 AM, edmund ronald wrote:
>
> CUPS is in all Linux distributions. Gnome, KDE, etc come and go, and are
> more fragmented. Maybe we should add the color stuff into the common CUPS
> management interface and its API, rather than the superstructure?
>
>
> Not possible, IMO. Apple is the maintainer of CUPS and in 1.6 is making a
> very aggressive change in direction that may turn out to be incompatible
> with the direction Linux printing wants to go in. PostScript is going away,
> that includes PPDs, in favor of IPP Everywhere.
>
> And in any event, Apple will not stuff such things into CUPS. It's not in
> their interest to do so. For Linux, color will have to be implemented
> outside of CUPS.
>
> We can see for Apple that desktop is in the ~10-20% of their bottom line,
> and shrinking. iOS is where the mass of the market is moving, and they
> don't want manufacturer specific drivers and experiences on iOS - or the
> future merged iOS and Mac OS. I have little doubt Epson's craptastic
> drivers were some of the kindle that lit this fire.
>
>
> Of course, you're all smarter than me, and actually do the work, but I do
> think that building a common infrastructure for print color might be a
> better idea than fragmenting the base facilities among interface projects
> and distributions.
>
>
> Well this has always been an issue with OSS. People have their own ideas
> how certain things should work. Real voluntary relationships have the
> potential for collaboration as well as fracturization risk. The
> fracturization here tells me we don't thoroughly understand what needs to
> be done, what it should look like, how it should behave. But something
> needs to happen so, let's make an attempt and see what happens.
>
> Hopefully, the historical case of the Apple and Microsoft attempts (how
> they differ, why both are problematic at best) is taken into account in the
> Linux attempts so history doesn't repeat itself. Or anything even remotely
> like it.
>
>
> Chris Murphy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20120227/40e74b6b/attachment.htm>