<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On May 10, 2011, at 2:44 AM, Jan-Peter Homann wrote:</div><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><font class="Apple-style-span" color="#000000">...<br></font>
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></div></blockquote><div><br></div>That is the idea; how quickly that happens obviously depends on a lot of things, but I think we've been able to take care of the basics in CUPS such that a fully-functional client could print without concerning itself with PPD files (which then just become an implementation detail of the CUPS driver model).</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">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></div></blockquote><div><br></div>Not my call, but I don't think this is an either-or situation - the CPD can provide the necessary glue and abstraction for printing from an app, and the use of PPD files in the CPD is an implementation detail the application need not be concerned with.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">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></div></blockquote><div><br></div>We'll still want a place to expose the printer's actual device profiles, so while the standard color space profiles might go away the device profiles (and the job template attributes used to automatically select them) would stay (otherwise you can't do color proofing...)</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
<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;"><font class="Apple-style-span" color="#006312" face="Helvetica"><span class="Apple-style-span" style="white-space: normal;">...</span></font></pre></span></blockquote></div></blockquote></div></blockquote><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><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></div></blockquote><div><br></div>I'll add a "relative-bpc" keyword with an informative reference to the Adobe document.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><blockquote cite="mid:ACF6E019-189F-4726-AC3B-131B022319D7@apple.com" type="cite"><div><div><font class="Apple-style-span" color="#144FAE">...</font></div></div></blockquote></div></blockquote><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><blockquote cite="mid:ACF6E019-189F-4726-AC3B-131B022319D7@apple.com" type="cite"><div><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.</div></blockquote><div><br></div>True, however we have often run into situations where subsets and multiple versions become a testing and interoperability nightmare. In the Linux space, Xpdf/poppler already supports most of what is needed and even Mac OS X printing only uses PDF 1.5 features, as nothing was really added to PDF after 1.5 that is applicable to printing. We chose PDF 1.7 because it is the only standardized version of PDF with 16-bit and transparency support.</div><div><br></div><div>I have a pending proposal for a printer attribute that lists the supported versions and extensions of PDF.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"> 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></div></blockquote><div><br></div>PDF 1.3 lacks transparency support, which is pretty much required for any modern graphics. Also, I hesitate to treat DeviceRGB as sRGB in PDF - we (Apple) made that mistake early in Mac OS X and are still dealing with the consequences.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
- PDF/X-1a<br>
- PDF/X-3<br>
- PDF/X-4<br>
- ISO 32000<br></div></blockquote><div><br></div>PWG also has PDF/is (image streamable) for facsimile and scanning applications.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">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></div></blockquote><div><br></div>The whole issue of rendering intent seems to not be well-addressed, which is why we have a separate job ticket attribute to specify it for whatever document format is used.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">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></div></blockquote><div><br></div></div>I'm not sure what the right answer is for this use case - tagging with the printer (or a custom user) device profile can lead to edge cases like this, but I don't think it is appropriate to use a job ticket attribute to address an issue with a specific file format (e.g. "pdf-output-intent") or to require the client to massage such files to get proper output.<div><div><br></div><div><div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>________________________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></span>
</div>
<br></div></div></div></body></html>