[Printing-architecture] Make use of extended color spaces on IPP printers

Solomon Peachy pizza at shaftnet.org
Sat May 8 23:52:18 UTC 2021


On Sat, May 08, 2021 at 12:11:51AM +0200, Till Kamppeter wrote:
> WDYT, would it also make sense to also switch to Adobe RGB (if available on
> the printer) if the user sets print-quality=high?

The colorspace is a property of the submitted printjob. As transforms 
into different colorspaces are inherently lossy, it must only be done
if/when absolutely necessary.

At the end of the day, there are only really three basic scenarios:

 1) Printjob is submitted in the printer's native/preferred colorspace,
    eg due to a fully color-managed workflow.
 2) Colorspace-aware printer that will parse embedded ICC profiles and
    transform data into the printer's native colorspace.
 3) Non-colorspace-aware printer

This leads to a handful of requirements:

 1) It must be possible to tell the printer that the job is already in 
    its native/preferred colorspace.  (It's called various things in 
    UIs, such as "disable color correction" or "host-managed color")
 2) The job *must* support embedding an arbitrary ICC profile
 3) If there is no embedded ICC profile and the "host managed color" 
    option is not set, just assume everything is sRGB

Notes:

 * "Printer" and "Printer Application" are interchangeable here
 * "Printer native colorspace" is arbitrary, and defined by an ICC profile.

With respect to (2), It seems the PWG raster format only defines a 
handful of colorspaces via ColorSpaceEnum; eg DeviceRGB, sRGB, and 
AdobeRGB.  This is a weakness vs JPEG or PDF (which allows arbitrary 
profiles.  Can we rely on that ColorSpace field being set correctly?

(In practice, IPP client UIs seem to be _very_ lacking when it comes to 
 exposing supported options...)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20210508/26179366/attachment.sig>


More information about the Printing-architecture mailing list