[Openicc] Thoughts IEEE PWG, ICC and PDF

[Michael Sweet]

On May 10, 2011, at 2:44 AM, Jan-Peter Homann wrote:
> ...
> 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 ?

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).

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

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.

> 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.

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...)

>>> ...
>>> 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

I'll add a "relative-bpc" keyword with an informative reference to the Adobe document.

>> ...
>> 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.

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.

I have a pending proposal for a printer attribute that lists the supported versions and extensions of PDF.

> 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 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.

> - PDF/X-1a
> - PDF/X-3
> - PDF/X-4
> - ISO 32000

PWG also has PDF/is (image streamable) for facsimile and scanning applications.

> 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.

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.

> 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.

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.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110511/e369af0c/attachment.html>