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

edmund ronald edmundronald at gmail.com
Thu May 10 01:19:43 PDT 2012


Hi folks,

 It appears that CM is now an integral, always active part of the
print system, and we are extremely happy that this is so, and we are
aware that considerable time and effort  has been spent on making it
so.

 However, as Gutenprint developers we believe we are allowed to
request that a feature be added in the print system to help *us* with
engineering.
 We have specific needs when developing drivers for new
hardware/media, and when coordinating with contributors and testers to
determine media settings.

 After a discussion with Robert, I would like to explicitly like to
ask that "CM-off" for a print queue, functionality that makes sure
that all data which goes out on a given queue is unmangled,  be added
as a documented and maintained  engineering facility to the whole
stack above us.
 We wish to be able to pass deviceRGGB, deviceCMYK etc data through to
the printer from *any* app that prints to *that* queue, without
affecting the rest of the print system.

 We wish for the CM-off functionality that disables CM for for a given
print queue to be a maintained documented "full citizen" feature of
the system, that exists independently of any local graphical
interface. It could be materialized eg. by a keyword in the PPD, a
control in the CUPS interface, a command line on/off utility, an API
call. We need it to be integral to future distributions.

 How the CM-off functionality is obtained is of course open to system
architects above us. We just need it to be officially there, and
usable without strange contortions.

 As open source printer driver developers we understand that we live
close to the hardware, and our role is to make sure that the right
amount of the right inks gets sprayed on the paper, and generally stay
out of the way; however there are cases when we specifically *need*
some engineering tools to be provided, and this such a case.

Edmund


More information about the openicc mailing list