[Openicc] [Gimp-print-devel] [Printing-architecture] Colour

[Hal V. Engel]

On Friday 13 November 2009 08:51:17 pm Michael Sweet wrote:
> On Nov 13, 2009, at 4:04 PM, Robert Krawitz wrote:
> > ...
> > Gutenprint absolutely provides a true DeviceN color path (for Epson
> > printers, at any rate).  We just don't have a reasonable vehicle for
> > exposing it to end users.
> 
> Right, as a "halftone module" Gutenprint actually offers much more than
>  most vendor solutions, however as a CUPS driver it has no way to expose
>  this since no RIP filter supports more than 4 channels.

Of course right now we don't have any open source *toraster filters that are 
color management aware and the only reasonable way to drive a DeviceN, where N 
> 4, device is to use ICC profile driven separations.  Since work is underway 
on the new pdftoraster filter to add CM support shouldn't it be capable of 
doing DeviceN separations if it is supplied a DeviceN output ptofile?  After 
all we have CMMs (LCMS) that support DeviceN profiles so it should be fairly 
simple for the new pdftoraster filter to generate the correct separations if 
the device profile is a DeviceN profile or if the PDF spool file has been 
prematched using a DeviceN profile.  What happens now if CUPS gets a PDF spool 
file that has been prematched to DeviceN?  Does it fail even if the device 
supports DeviceN and the separations are correct for that device?  Or does it 
convert it to some other format like CMYK?

I thought that GPLin was driving Epson printers as DeviceN devices.  But I may 
not have that correct.  Alastair care to comment?

> 
> > I'm dubious of sRGB-only command sets for inkjet printers.  It
> > artificially restricts the available gamut, and doesn't work if you
> > use a medium other than that specified by the manufacturer.
> 
> Like it or not, you're going to see more sRGB/AdobeRGB-only devices in the
>  future, even from Epson. Only the high-end printers will support a DeviceN
>  mode that can be used by third-parties...

Again almost no one here is using the hardware vendor supplied drivers.  So I 
don't think it matters much what they do.  Our GutenPrint driven printers will 
continue to support DeviceN and CMYK print modes (even on low end devices) 
regardless of what the hardware vendors choose to do other than refusing to 
supply documentation for the printers communications protocol.  Some vendors 
have been refusing to supply this documentation for a long time but these 
vendors end up not having much penetration into the FOSS market so they are 
seeding this market segment to those vendors that supply the documentation 
needed to write open source drivers.

Hal