[Openicc] Thoughts IEEE PWG, ICC and PDF

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  
compliant ?

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.

Jan-Peter:
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.
Jan-Peter:
I agree, this a very powerful feature for doing client side 
colormanagement on very high level, also adressing the needs of graphic 
arts.
>> 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?
>
Jan-Peter:
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)
- perceptual
- saturation

>
> 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.
Jan-Peter:
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 
elements.
Such subsets could be e.g.
- PDF 1.3 DeviceRGB only (simplest subset for sRGB printing workflow)
- PDF/X-1a
- PDF/X-3
- PDF/X-4
- 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 
colorspace.
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...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110510/f80d73f5/attachment.htm>