<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&nbsp; 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>