[Printing-architecture] Make use of extended color spaces on IPP printers
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
* "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 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...
Size: 833 bytes
Desc: not available
More information about the Printing-architecture