[Openicc] GoSoC 2011: CPD and target printing

[Chris Murphy]

On May 13, 2011, at 4:41 PM, Michael Sweet wrote:

> On May 13, 2011, at 3:26 PM, Chris Murphy wrote:
>>> ...
>>> None of these things requires a dedicated app - RIPs already provide them on Mac OS X.
>> 
>> A RIP is a dedicated app.
> 
> Not always. RIPs can be general purpose programs in the CUPS filter chain, replacing the default one in Mac OS X (cgpdftoraster) or embedded in a larger printer-specific solution (which is how a lot of them are packaged for the Mac...)

I've never seen one single application or RIP I've ever used replace cgpdftoraster. I can't imagine Adobe would touch this with a 10 foot pole.

> 
>> Are you seriously suggesting that rendering intent control and black point compensation belong on a RIP, and not in the print driver and not in Photoshop? That's a total non-starter for a meaningful conversation about sticking to Mac OS as a platform.
> 
> I am saying that if you want a custom CMM for all printing, the place to put it is in a RIP if you want it to apply to all applications.  Standalone "drag a file onto the RIP application icon" RIPs are a non-starter IMHO since they make it too hard for a user to print using the RIP.  Application color management has similar issues since you only get the special CMM for content from that app.

This is a huge barrier to innovation with 3rd party CMMs. It's why it's not happening anymore. It's why we need application-level color matching. No developer is going to screw around with this level of modification of the operating system, even if CUPS is expressly designed to allow for it. 

And we still need rendering intent and BPC and none of this is available in any Apple provided GUI or print driver PDE. So application color matching is where it's at for < 90% of all ICC based workflows. I really don't see much use for ColorSync in the print dialog, the default of sRGB plus proprietary matching works for all remaining users adequately and even some professionals use it for simplicity and does a pretty decent job most of the time. For the more discerning users, they're not going to use color management in today's print dialogs because they are too limiting.

You couldn't implement color management for an app like InDesign where you need a rendering intent control for each object.

And the future of PDF and printing is the ability to print a single job with multiple destinations: cover is printed on media in Tray 1, most internal pages from Tray 2, and a few inserts printed on Tray 3. So that's multiple OutputIntents - and we can't do that in a system print dialog either. So again, application level color management is here to stay for the very fact we don't need such complexity and clutter in a general purpose print dialog. This is why we have app level color management. It can't nor should it go away.


> 
>> ...
>> a.) Most applications do not use kPMApplicationColorMatching. Only two use it right now as far as I know. I'm not suggesting all applications be capable of producing /DeviceRGB in PDF print spools, just those applications that call kPMApplicationColorMatching for the express purpose of disabling ColorSync for printing profile targets and prematched image data.
> 
> That is, in fact, one of my "pitches" for the simple API.

Good luck, I've been pitching it for 7 years and I keep getting "death to /DeviceRGB".


> 
>> b.) There is no user or application access to the pdf print spool file.
> PDF workflows (which were added in 10.4 I think) give you access, and CUPS allows the owner of a job to access the spooled jobs since 10.6.

/var/spool/cups is owned by system, everyone else has no access, on 10.6.7 and since forever. I've always had to change their owner or add an ACL to access the spooled jobs.

Anyway, there is no meanginful or practical user access that would pose a problem in normal function of the system. That spool file lives for a VERY short amount of time. Interception and interaction is non-obvious.



> 
>> ...
>> c.) If an application tags data Generic RGB and submits it to the OS, it's changed by the Quartz PDF Context into sRGB.
> 
> Actually, it is technically Generic RGB Gamma 2.2, which looks a lot like sRGB. And that is only for the convenience functions in CG, not for image content.

OK.


Chris Murphy