[Openicc] Gutenprint team requests CM-off for a print queue be provided as a maintained engineering facility.

[Chris Murphy]

On May 11, 2012, at 5:32 PM, edmund ronald wrote:

>> I don't see how this is possible with PPDs. You'd still need the PPD method to trigger a common API for colord and Oryanos. Unless the PPD entry could somehow trigger Ghostscript directly, which then implies that Ghostscript of a particular version is always available whenever system wide opt in color management is also on that system.
> 
> Why can't every future version of ghostscript for Linux systems have
> our CM-off switch? I mean, if color management is this important to
> everybody, and Gutenprint is the designated backend, surely some
> accomodation for diagnostic facilities can be reached?

It's not clear to me the mechanism by which the PPD actually causes "no transform, device color" to occur. Something must interpret this PPD entry and either:

1.) cause some metadata to be inserted into the resulting print spool file or job ticket, which is interpreted by a downstream raster engine to contravene a "transform these objects in this manner" instructions.

2.) cause the service that actually produces the print spool file to not contain "transform these objects in this manner" instructions.

If #1, this is a problem in my view because it demands a downstream raster engine to 2nd guess the contents of the spool file with an override. The problem, as I've argued before, is not with the PDF engine. It is with the PDF print spool file asking for a transform when it shouldn't. And while an "add on" piece of metadata in the PDF or a job ticket that acts as an override may be the only way to reliably do this, I'm skeptical at the moment.

	a.) Can this work for PDF, PS, and XPS direct to printer output?
	b.) Is Ghostscript guaranteed to be in the print pipeline?

If #2, how does a PPD instruction cause myriad print spool writers to behave this way on demand? Wouldn't they all have to support the PPD instruction?

It seems to me the "thing" that is enabling color management to being with is the "CMS" or "CMS-like-thing" which is either colord or Oyranos. And because of that, those are my prime suspects for dealing with this.

In any case, an API is needed. Or do we allow apps to modify PPDs, or create derivative PPDs, just so that profile targets and prematched data can be properly printed?

And if an API is needed, then it seems a CLI tool meets the requirements. It's also more broadly applicable, by device, not just raster PDF device, but XPS direct to device, or display.

However, maybe more than one API is needed. The CLI tool, I'd be OK with it disabling transforms per device or per queue. But I don't really want an application to have that kind of privilege except per job or per instance. So that's for the engineers to sort out. I don't want a way ward application capable of negating color transforms for other devices, or all applications going to a device. Right?


Chris Murphy