[Openicc] Is CUPS the right place... (CUPS and ColorSync)

[Chris Murphy]

And nothing I've previously said gives Epson crappy driver development a pass. They are constantly doing things they're not supposed to do. And while other vendors producing drivers for OS X have had problems also, they eventually got it sorted out while Epson (and Canon) have had notorious problems that just keep on dragging out.

But not on Windows. So maybe there's some small advantage to lack of change and innovation.

Chris


On Feb 7, 2011, at 6:10 PM, edmund ronald wrote:

> Actually, Photoshop CS5 users were also getting hosed by an
> interesting little Photoshop bug that had nestled in the application
> color matching printpath, and that hosed the first print.
> 
> Edmund
> 
> On Tue, Feb 8, 2011 at 2:01 AM, Chris Murphy <lists at colorremedies.com> wrote:
>> On Feb 7, 2011, at 5:51 PM, Leonard Rosenthol wrote:
>>> 
>>> If a PDF file contains DeviceRGB or DeviceCMYK objects, ColorSync will
>>> change such PDF objects automatically and without warning to ICCbased mainly
>>> by embedding e.g. the ColorSync standard profiles in every PDF object
>>> (images, vector graphics, text...)
>>> 
>> 
>> Apple/Quartz/ColorSync doesn't change anything UNLESS you explicitly ask it
>> to.
>> 
>> I suppose that's a matter of perspective. If it's a high level, then this is
>> not true. Apple/Quartz/ColorSync is an opt-out color management system, not
>> opt-in. It will do conversions unless you explicitly tell it not to, with
>> one exception and that's /DeviceCMYK to a CMYK device (or PostScript file)
>> and in that case it is pass through.
>> In the case of professional photo printing with RGB output devices like
>> inkjet printers, we're constantly getting hosed by Apple's system because
>> Adobe products keep having to ask Quartz to do NO MORE CONVERSIONS and yet
>> routinely Quartz persists in converting in cases where we don't want it to.
>> And a big part of why that happens is because the application correctly sets
>> the OutputIntent, but the SPI provided by Apple does not guarantee that all
>> objects in the PDF have ICCBased spaces that match the OutputIntent. Because
>> of this, Quartz *WILL* do conversions on those objects when there is a
>> mismatch between source and destination, even though the application that
>> asked for that PDF to be written out with an SPI calling for NO MORE
>> CONVERSIONS.
>> From another perspective, Core Graphics is only doing what it's told to do
>> in the PDF. So arguably the PDF is written incorrectly, in that it's going
>> to ask for a conversion that we don't want to have happen. And my argument
>> has been that if Apple is going to depend on null transforms as the only
>> means of disabling ColorSync in the print pipeline, then they need to
>> provide a robust API that ensures PDF's written out by Quartz PDFContext
>> contain object source profiles that match the OutputIntent.
>> 
>> 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