attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ryan,<div class=""><br class=""></div><div class="">Thank you for your detailed feedback.</div><div class=""><br class=""></div><div class="">Overall, I think you may have misunderstood the scope of what is being defined in the white paper - one of the primary purposes of our discussions is to advance beyond the simple "slicer, printer driver, and toolpath file" model that has been used for 3D printing. We know (from painful experience over the last 60+ years of computer-driven 2D printing) that the printer driver model does not scale and leads to bad output, security problems, and even safety issues. The same is true of 3D printing, with even more dramatic failures.</div><div class=""><br class=""></div><div class="">Given that inexpensive devices such as the Raspberry Pi are sufficient to perform machine control and slicing for "consumer" 3D printers, our focus is on a higher-level interface where the client sends the model geometry ("Object Information File") separately from the print options ("Job Template" attributes in IPP, also known as a Job Ticket). Slicing and device control happen in the printer (or some box connected to the printer or in a cloud service) so that the client does not need to have a device-specific "printer driver", just a generic one for all printers.</div><div class=""><br class=""></div><div class="">This focus may not be explicit enough in my white paper, so I'll make sure to provide more background in the next version I post...</div><div class=""><br class=""></div><div class="">....</div><div class=""><br class=""></div><div class="">Regarding exceptions, IPP (and the PWG Semantic Model) use keywords (strings) to report device state. Integers, while compact, are basically impossible to extend safely, and require client software to understand their meaning to report something meaningful to the user. So what we have in IPP's printer-state-reasons attribute is a list of keywords representing the device's current state, and should a vendor need to define a new state keyword we have a naming convention for doing so as well as a registry for well-known values and a way for the printer to provide the client with a translation dictionary so the keywords can be converted to a human-readable message.</div><div class=""><br class=""></div><div class="">The goal, of course, is to pre-define most of the needed state keywords so vendors do not need to define their own. And the list of common keywords (just like the white paper itself) can be updated periodically over time.</div><div class=""><br class=""></div><div class=""><span style="font-family: 'Andale Mono'; orphans: 2; widows: 2;" class="">_________________________________________________________</span></div><div class=""><div apple-content-edited="true" class=""><div class=""><span style="font-family: 'Andale Mono'; orphans: 2; widows: 2;" class="">Michael Sweet, Senior Printing System Engineer, PWG Chair</span></div>
</div>
<br class=""></div></body></html>