[Openicc] Thoughts IEEE PWG, ICC and PDF
homann at colormanagement.de
Tue May 10 02:44:30 PDT 2011
Hello Michael,(cc Leonard and OpenICC list)
Thank you very much for correcting my wrong first impressions on color
management and IPP PWG. The workflow concept has definetely the needed
ground for offering an ICC based colormanagement printing path.
Is my impression correct, that the IPP concepts delivers a communication
channel between print service and print client, which makes PPDs
obsolete in the future ?
Is it also the case, that the Common Printing Dialogue under LINUX will
be replaced by an IPP PWG client application if the print server is IPP
Further more I make some comments directly in the text and start an
OpenICC subpage concerning InternetPrintingProtocol
Am 09.05.11 20:19, schrieb Michael Sweet:
> [Again, apologies for not replying to the original thread...]
> Jan Peter Homann wrote:
>> Hello to all,
>> Reading "wd-ippjobprinterext3v10-20110330.pdf"
>> seems to be quite strange to me.
>> The ICC profiles used as example, are typical ICC-profile for exchange
>> of documents.
> Correct. The printer either provides vendor profiles resident on the
> printer or references to standard color profiles if those are all the
> printer supports. However, we also have an open issue on the current
> definition since (except for sRGB) the "standard" color space
> references are not available from a durable URL.
If the supported print spool formats allow to embed the document profile
into the print spool file, I don´t see the need for a second
communication layer of the document colorspace. I think, this part of
the specs could / should be deleted in a future version of the spec.
> IMHO the really interesting use of printer-icc-profiles is for color
> proofing. I fully expect most clients to provide documents using
> standard color spaces or (in the case of PDF) using embedded color
> profiles. For client-managed color (printing targets and documents
> using local device color profiles) the client will provide documents
> with supported device color spaces.
I agree, this a very powerful feature for doing client side
colormanagement on very high level, also adressing the needs of graphic
>> Also the rendering instructions in "5.2.2 print-rendering-intent" are
>> not practical.
>> If relative colorimteric is used as default for printing, there should
>> always be blackpoint compensation be activated. Otherwise, it may will
>> happen that details in dark tones are lost during printing.
> Do you see a need for additional attributes to specify a white point
> or black point? Or is the summary confusing/inaccurate?
I don´t see the need for specifying white points or black points, but
offering for relative colorimetric matches the option for blackpoint
compensation according Adobe spec publishes by ICC as whitepaper here:
http://www.color.org/AdobeBPC.pdf (unfortunately, it is currently only a
white paper and not part of the spec...)
This would lead in part 5.2.2. to five rendering strategies:
- absolute colorimetric
- relative colorimetric
- relative colorimetric with blackpoint compensation (default)
> Yes, the printer provides a list of supported MIME media types to the
> client ("document-format-supported") so that it may choose the best
> format to use for a particular job. The JPS3 spec also defines
> "preferred" values that a printer can supply to the client as a hint.
>> - If PDF is supported, which flavours / elements of PDF would be supported ?
> All of the required printing/static presentation elements from PDF
> 1.7/ISO 32000 would be supported.
Supporting all required printing/static presentation elements from PDF
1.7/ISO 32000 is quite a challenge. I would recommend for future
versions of the spec, that it allows to define subsets of supported PDF
Such subsets could be e.g.
- PDF 1.3 DeviceRGB only (simplest subset for sRGB printing workflow)
- ISO 32000
Please note, that there are some issues with the PDF specs and color
managed printing, which are currently not well defined in the specs:
1) Blackpoint compensation for ICCbased objects:
Currently all avilable PDF specs don´t allow to specify, that a ICCbased
object should be rendered with blackpoint compensation to the output
There are several applications (including PDF renderers from Adobe and
Apple), which allow the user to active blackpoint compensation for this
case. (May be, the default settings of some PDF renderers have
blackpoint compensation already active...).
Adobe, ICC and ISO TC 130 are working on this issue, ans may be Leonard
can tell us the current state of developments.
2) PDF Output Intent does not match printers colorspace
Especially in the graphic arts, it is common to work partly in
DeviceCMYK standard colorspaces (SWOP, ISOcoated_v2...) and integrate
the PDF output Intent as a description of the document colorspace in
PDFs, whiche are sent to print service (provider).
If the printing process do not matches, the PDF Output Intent, the
avilable PDF specs do currently not provide a guideline for color
management of such files.
Combining PDF and IPP PWG specs, could may lead to following workflow:
1) All PDF content is rendered to the Output Intent first
2) the transformation from Output Intent to Printer colorspace is done
according the IPP PWG metada specified for the individual print job.
---------- Please note the new adress --------------
homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openicc