[argyllcms] Re: [Openicc] Re: Re: OT: PDF frustration
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx, OpenICC Liste <openicc@xxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 07 Oct 2008 18:17:22 +1100
Kai-Uwe Behrmann wrote:
It would make sense to me, that this object applies especially to the
device colour spaces. E.g. so retargeting would allow for a conversion
from a deviceCMYK colour space of one printing device to say a proofing
device. Including the answere of Graeme, I hope we are all in sync ;-)
I'm not so sure. The PostScript/PDF line of page description languages
has the concept of "device" input colors. In older versions of
PostScript they typically mapped to the actual output device
space (or went through some crude translations if the output
space didn't match, ie. RGB->CMYK). Newer versions of PostScript
and PDF allow these input device color spaces to be intercepted,
and "emulated" by (say) an input profile of some sort,
allowing the device spaces input color specification to
be actual output device independent.
For PostScript, see the PLRM3 Figures 4.5 and 4.6 on pages
212 and 213. The equivalent diagram for PDF V1.7 reference
manual is figures 4.12 and 4.13 on pages 238 and 239.
This is not to be confused with how all of the input color
specifications are then translated into the actual output
device colorspace.
For PostScript, the output "profile" is defined by
the Color Rendering Dictionary, and this is detailed
in chapter 7 of the PLRM3.
For PDF, the equivalent concept is in chapter 6.1,
but there is no equivalent to the CRD, although PDF 1.4
introduced the concept of output intents, that does
provide a mechanism to hint at an output profile,
and this is detailed in section 10.10.4 page 970
of PDF 1.7 spec.
As I see, the issue remains, as a complete control would only be given if
the gamut mapping could be controled.
What about retargetting. Will CUPS be made thinking it is "clever" and
touches on deviceCMYK to move to a different output colourspace? Why not?
What are the rules to print real Cmyk numbers? - a missing output intent
object? Would be logical - deviceCMYK keeps deviceCMYK.
Please correct if the PDF spec says otherwise.
These details depend on the usage. Typically people don't want deviceCMYK->
output CMYK, because it becomes unpredictable, they want the deviceCMYK
input color space to be a standard color space (like SWOP or the more
modern equivalents). It's only special users who want real device
space (ie. for printing profile/calibration test charts etc.).
There's really no substitute for reading the appropriate chapters
of the PDF reference manual. It's quite well written, although
may take a little time to fully comprehend the full scope of it.
The worst in this design is that, in order to print untouched Cmyk CUPS
required one has to provide the cupsICCProfile specified profile. This
goes in circles as it clearly strikes platform independence.
Any practical printing system needs a mechanism to allow bypassing
of normal color processing to allow the system to be calibrated and
profiled. For some systems there may be three separate levels of
processing, each of which needs to be able to be bypassed:
Calibration (i.e. device ink channel linearisation)
Separation (ie. RGB->CMYK, or CMYK->CMYKcmOG etc.)
Profiling (ie. RGB, CMYK, CMYKcmOG etc.)
Graeme Gill.
Other related posts:
