<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Michael,(cc Leonard and OpenICC list)<br>
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.<br>
<br>
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 ?<br>
<br>
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 ?<br>
<br>
<br>
Further more I make some comments directly in the text and start an
OpenICC subpage concerning InternetPrintingProtocol<br>
<br>
Am 09.05.11 20:19, schrieb Michael Sweet:
<blockquote
cite="mid:ACF6E019-189F-4726-AC3B-131B022319D7@apple.com"
type="cite">[Again, apologies for not replying to the original
thread...]
<div><br>
</div>
<div>Jan Peter Homann wrote:</div>
<div>
<blockquote type="cite"><span class="Apple-style-span"
style="font-family: 'Helvetica Neue';">
<pre style="white-space: pre-wrap;">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.
</pre>
</span></blockquote>
<div><br>
</div>
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.</div>
</blockquote>
<br>
Jan-Peter:<br>
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.<br>
<blockquote
cite="mid:ACF6E019-189F-4726-AC3B-131B022319D7@apple.com"
type="cite">
<div><br>
</div>
<div>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.</div>
</blockquote>
Jan-Peter:<br>
I agree, this a very powerful feature for doing client side
colormanagement on very high level, also adressing the needs of
graphic arts.<br>
<blockquote
cite="mid:ACF6E019-189F-4726-AC3B-131B022319D7@apple.com"
type="cite">
<div>
<blockquote type="cite"><span class="Apple-style-span"
style="font-family: 'Helvetica Neue';">
<pre style="white-space: pre-wrap;">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.
</pre>
</span></blockquote>
<div>Do you see a need for additional attributes to specify a
white point or black point? Or is the summary
confusing/inaccurate?</div>
<div><br>
</div>
</div>
</blockquote>
Jan-Peter:<br>
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:<br>
<a class="moz-txt-link-freetext" href="http://www.color.org/AdobeBPC.pdf">http://www.color.org/AdobeBPC.pdf</a> (unfortunately, it is currently
only a white paper and not part of the spec...)<br>
<br>
This would lead in part 5.2.2. to five rendering strategies:<br>
- absolute colorimetric<br>
- relative colorimetric<br>
- relative colorimetric with blackpoint compensation (default)<br>
- perceptual<br>
- saturation<br>
<br>
<br>
<blockquote
cite="mid:ACF6E019-189F-4726-AC3B-131B022319D7@apple.com"
type="cite">
<div>
<div><br>
</div>
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.</div>
<div><br>
<blockquote type="cite"><span class="Apple-style-span"
style="font-family: 'Helvetica Neue';">
<pre style="white-space: pre-wrap;">- If PDF is supported, which flavours / elements of PDF would be supported ?
</pre>
</span></blockquote>
<div>All of the required printing/static presentation elements
from PDF 1.7/ISO 32000 would be supported.</div>
</div>
</blockquote>
Jan-Peter:<br>
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.<br>
Such subsets could be e.g.<br>
- PDF 1.3 DeviceRGB only (simplest subset for sRGB printing
workflow)<br>
- PDF/X-1a<br>
- PDF/X-3<br>
- PDF/X-4<br>
- ISO 32000<br>
<br>
Please note, that there are some issues with the PDF specs and color
managed printing, which are currently not well defined in the specs:<br>
<br>
1) Blackpoint compensation for ICCbased objects:<br>
Currently all avilable PDF specs don´t allow to specify, that a
ICCbased object should be rendered with blackpoint compensation to
the output colorspace.<br>
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...). <br>
<br>
Adobe, ICC and ISO TC 130 are working on this issue, ans may be
Leonard can tell us the current state of developments.<br>
<br>
2) PDF Output Intent does not match printers colorspace<br>
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).<br>
<br>
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.<br>
<br>
Combining PDF and IPP PWG specs, could may lead to following
workflow:<br>
<br>
1) All PDF content is rendered to the Output Intent first<br>
2) the transformation from Output Intent to Printer colorspace is
done according the IPP PWG metada specified for the individual print
job.<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
---------- Please note the new adress --------------
homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- <a class="moz-txt-link-freetext" href="http://www.colormanagement.de">http://www.colormanagement.de</a>
10407 Berlin -------- <a class="moz-txt-link-freetext" href="mailto:homann@colormanagement.de">mailto:homann@colormanagement.de</a>
</pre>
</body>
</html>