<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 25, 2012, at 11:55 AM, edmund ronald wrote:</div><blockquote type="cite">Michael,<div> </div><div>I don't  quite understand 16 bit colorN as a solution to most printing problems, at least for Gutenprint.</div></blockquote><div><br></div>Normally Gutenprint performs internal transforms from CMYK or (s)RGB to DeviceN using calibrations for specific media and resolution settings.  Gutenprint also provides an uncalibrated DeviceN path that provides access to each ink individually vs. mapped from RGB or CMYK.</div><div><br></div><div>Current ICC-based solutions use the RGB or CMYK paths to "calibrate" the color - you print a target image, measure the target, generate a profile, and use it.</div><div><br></div><div>As others have noted, relying on existing calibrations for new media or ink does not always work well.</div><div><br></div><div>We can choose to pass calibration data to Gutenprint, perhaps through ICC profile metadata, but that doesn't solve the general profiling case and requires a special app to profile just for Gutenprint.</div><div><br></div><div>We can also choose to support an uncalibrated 16-bit DeviceN space where 0 means no ink and 65535 means 100% ink (for each color). This supports having a general profiling application and is not driver-specific.  And certain key information (such as number and type of colorants) could be supplied as PPD keywords for the Gutenprint driver ("this is a 7-color printer with C, LC, M, LM, Y, K, LK inks") which would take care of the initial defaults when working with standard colorants for the printer.</div><div><br></div><div>I will grant that the general DeviceN design has a serious issue: there are no DeviceN color profiling tools (generally?) available to support N > 4, which means that Open Printing would be treading on new ground.  There is also the issue of printer modes - depending on the media you might choose between two different sets of drop sizes, for example; in that case we are back to the "how do I tell the printer/driver that I have a derivative media type?" question, which I proposed could simply be an extension naming scheme.</div><div><br></div><div><blockquote type="cite"><div><br></div><div>Maybe you could outline a realistic way you think the system would operate, so we can understand the intended design philosophy.  </div> <div><br></div><div>Edmund</div><div><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 5:10 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Jan 25, 2012, at 2:19 AM, Kai-Uwe Behrmann wrote:<br> > ...<br> </div><div class="im">> As it was not clear in the past how to place Gutenprint calibration data passed along PPD files, I am much interessted how does the situation change for that through IPP.<br> > How do you plan to populate your calibration data along Gutenprint vendor ICC profiles in a IPP world? Do you plan to make use of the IPP "printer-icc-profiles" attribute and the associated job ticket attributes?<br> <br> </div>Gutenprint "calibration" data isn't something that can be passed as options presently; at the IPP level we can support sending arbitrarily-long lists of numbers (as might be used for a lookup table) as an attribute which the driver will see as a comma-delimited string on the command-line, however that seems like a poor solution in the long term since it requires the application or toolkit to furnish that data each time.<br> <br> (Gutenprint *does* have a real 16-bit per color DeviceN path, and if that path was supported by Ghostscript then that would likely be a viable option for an ICC-based workflow...)<br> <div class="im HOEnZb"><br> __________________________________________________<br> Michael Sweet, Senior Printing System Engineer, PWG Chair<br> <br> </div><div class="HOEnZb"><div class="h5">_______________________________________________<br> openicc mailing list<br> <a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br> </div></div></blockquote></div><br></div> _______________________________________________<br>openicc mailing list<br><a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a><br>http://lists.freedesktop.org/mailman/listinfo/openicc</blockquote></div><br><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: -webkit-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>__________________________________________________</div><div>Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></span> </div> <br></body></html>