attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Daniel,<div><br></div><div>Thank you for the response.</div><div><br></div><div>My own personal experience with various IPP implementations from consumer inkjet's through high-end light production office equipment shows that performance with multiple requests (in serial or parallel) introduces delays on the order of seconds with some printers. A delay of even 1 second can seem like an eternity in an interactive UI.</div><div><br></div><div>In some cases the overhead is with the implementation (low-end hardware with non-optimized IPP stack) and in other cases with the configuration (TLS, authentication, etc.) which introduces a lot of round trips and retransmissions. And many low-end printers limit the number of simultaneous client requests making a parallel request strategy cause more delays than simply issuing multiple requests over a single connection. Add IPP USB to the mix and you are *really* constrained in the number of parallel requests you can make.</div><div><br></div><div>Perhaps things like HTTP/2.0 and future TLS specifications will address many of the performance issues inherent in a parallel request strategy, but those are not yet available or implemented in production printers.</div><div><br></div><div>(FWIW, I don't regret defining these PDL-specific attributes: it has made printing an enjoyable experience for hundreds of millions of users.)</div><div><br></div><div>WRT the Semantic Model, there are already differences in what is defined in IPP and the SM, from operations (Get-Jobs + which-jobs vs. GetXxxJobs) to attributes (MediaType top-level element in SM that is not in IPP, various IPP operation attributes like "compression" that are not in the SM, etc.) IMHO the important thing is for the core semantics to remain the same, not to provide a directly-accessible SM element for every IPP attribute.</div><div><br></div><div>So I might not add xxx-k-octets-supported to the SM, but something like pdf-versions-supported would be a candidate since you can't get it from DocumentFormatDetails.</div><div><br></div><div><br><div><div>On Sep 13, 2013, at 7:33 PM, Manchala, Daniel <<a href="mailto:Daniel.Manchala@xerox.com">Daniel.Manchala@xerox.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Andale Mono";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1"><p class="MsoNormal"><span style="color:#1F497D">Michael,<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D">Thanks for the response to earlier comments from Xerox. Just a few additional comments on the same topic.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D">Given your explanation to Justin, and other “industry efforts”, Xerox will accept your rejection of 1 through 5 (copied below for reference), although we believe IPP should have avoided PDL specific attributes.
We have two ways to obtain the same information. The network overhead of attribute coloring is minimal and can be mitigated through parallel requests or technologies such as “Volley.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D">It is best the PWG mirror every IPP attribute in the PWG Semantic Model even if they are a side-effect of the protocol or of targeting specific markets/use cases. <o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">/Daniel.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D">Here are the five comments (copied from an earlier email note):<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">IPP Attributes should be document format independent. Existing semantics should be used when they exist or corrected when additional semantics are required.</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><o:p></o:p></span></p><p class="MsoListParagraph" style="margin-left:20.25pt;text-indent:-.25in"><span style="color:#1F497D">1)</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="color:#1F497D">“jpeg-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”.
</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p><p class="MsoListParagraph" style="margin-left:56.25pt;text-indent:-.25in"><span style="color:#1F497D">a.</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="color:#1F497D">Note that IPP attribute coloring can be used to obtain document format specific values when required.
</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p><p class="MsoNormal">In actual implementation, the existing attribute (with multiple queries) was too inefficient. This attribute has been widely implemented in IPP printers since 2010.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">My preference is to reject this request.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="margin-left:20.25pt;text-indent:-.25in"><span style="color:#1F497D">2)</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="color:#1F497D">“pdf-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”.</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p><p class="MsoNormal">In actual implementation, the existing attribute (with multiple queries) was too inefficient. This attribute has been widely implemented in IPP printers since 2010.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">My preference is to reject this request.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">(For reference, a Client might need to determine supported file formats and sizes in order to determine which format to send to the Printer. And certain file formats such as PWG Raster generally are streamed on both the Client and Printer
so the job-k-octets-supported value is MAX vs. some smaller value for PDF or JPEG)<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="margin-left:20.25pt;text-indent:-.25in"><span style="color:#1F497D">3)</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="color:#1F497D">“pdf-versions-supported” should be dropped in favor of the existing “document-format-details-supported” (“document-format” and “document-format-version” members).</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p><p class="MsoNormal">"document-format-version" is localized text, "document-format-details-supported" is a list of member attributes supported by the "document-format-details" attribute, and "document-format-version-supported" is a list of all of the localized
version strings that are supported for all formats that is optionally filtered by document-format when you do a Get-Printer-Attributes request.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Since there is no way to register localized text values, filtering those values with multiple Get-Printer-Attributes requests is inefficient, and this attribute is supported by most IPP+PDF printers since 2010, my preference is to reject
this request.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="margin-left:20.25pt;text-indent:-.25in"><span style="color:#1F497D">4)</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="color:#1F497D">“jpeg-x-dimension-supported” and “jpeg-y-dimension-supported” should apply to any image format. The names should be changed to “max-image-x-dimension-supported” and “max-image -x-dimension-supported”.</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p><p class="MsoNormal">These attributes have been widely implemented since 2010. And as I've noted before doing multiple Get-Printer-Attributes requests is really inefficient.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">My preference is to reject this request.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="margin-left:20.25pt;text-indent:-.25in"><span style="color:#1F497D">5)</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="color:#1F497D">“printer-dns-sd-name” should be applicable to any service. The name should be changed to “dns-sd-name”.</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p><p class="MsoNormal">With a few exceptions, we prefix all Printer Description attributes that are not associated with Job/Document Template attributes with "printer-". And since DNS-SD is a *service* discovery protocol, not a device discovery protocol, I don't
think dropping the "printer-" prefix or using an alternate prefix like "device-" makes sense. And FWIW CUPS has implemented "printer-dns-sd-name" for a very long time (since CUPS 1.2/2005 IIRC).<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="margin-left:20.25pt"><span style="color:#1F497D">Scaling should not be print specific.</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p><p class="MsoNormal">IPP = Internet Printing Protocol, so we are necessarily focused on printing. And as has been done in the past, SM can (and probably should) map print-scaling to ScalingMode (or whatever), just as print-quality is mapped to Quality, printer-resolution
=> Resolution, etc.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="margin-left:20.25pt"><span style="color:#1F497D">The PWG Semantic Model already defined a collection for scaling (i.e., “scaling”). Apparently we didn’t quite get it right. The current definition allows for explicit scaling
(i.e., “scaling-height” and “scaling-width”) or a boolean for “auto-scaling”. The explicit scaling member should be kept. The Boolean “auto-scaling” should be deprecating and an attribute with a unique name (e.g., “auto-scale-mode”) should replace it with
the semantics defined for “print-scaling” </span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p><p class="MsoNormal">FWIW, CUPS previously supported two other attributes for scaling in the past - "scaling" (scale to a percentage of the media size) and "natural-scaling" (scale to a percentage of the document size). This allowed for "poster" printing over
multiple media sheets, among other things, but had a lot of limitations and implementation issues. (BTW, we only ever supported symmetric scaling: scaling-width == scaling-height)<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">I *can* see the use case for copy - copy this hardcopy document and enlarge to 200% - but for print the 99% use case is "enlarge this document/image to fit/fill these (media) dimensions". In many cases there are no (reliable) physical
dimensions to work with, so saying "enlarge to 200%" has no meaning. However, you can always say "fit/fill the document data on the requested media".<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Also, the current Scaling group in SM is not part of the Print service, just under the Copy, FaxIn, FaxOut, and Scan services (under <service>DocumentProcessing).<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">My preference is to reject this request.<o:p></o:p></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:ipp-bounces@pwg.org">ipp-bounces@pwg.org</a> [<a href="mailto:ipp-bounces@pwg.org">mailto:ipp-bounces@pwg.org</a>]
<b>On Behalf Of </b>Michael Sweet<br>
<b>Sent:</b> Friday, September 06, 2013 10:05 AM<br>
<b>To:</b> Justin Hutchings<br>
<b>Cc:</b> <a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<b>Subject:</b> Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments<o:p></o:p></span></p>
</div>
</div><p class="MsoNormal"><o:p> </o:p></p>
<div><p class="MsoNormal">Justin,<o:p></o:p></p>
</div>
<div><p class="MsoNormal"><o:p> </o:p></p>
</div><p class="MsoNormal">Fair enough, we do have use cases but will highlight for each of the attributes.<o:p></o:p></p>
<div>
<div><p class="MsoNormal"><o:p> </o:p></p>
</div>
<div><p class="MsoNormal"><o:p> </o:p></p>
<div>
<div><p class="MsoNormal">On Sep 6, 2013, at 12:53 PM, Justin Hutchings <<a href="mailto:justhu@microsoft.com">justhu@microsoft.com</a>> wrote:<o:p></o:p></p>
</div><p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div><p class="MsoNormal"><span style="color:#1F497D">Thanks for your quick response, Mike. It might be worthwhile to articulate the rationale as to why these are required in the spec. I didn’t pick up on all that during my read through.
</span><o:p></o:p></p><p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p><p class="MsoNormal"><span style="color:#1F497D">Thanks!</span><o:p></o:p></p><p class="MsoNormal"><span style="color:#1F497D">Justin</span><o:p></o:p></p><p class="MsoNormal"><a name="_MailEndCompose"><span style="color:#1F497D"> </span></a><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> Michael Sweet [<a href="mailto:msweet@apple.com">mailto:msweet@apple.com</a>]
<br>
<b>Sent:</b> Friday, September 6, 2013 7:00 AM<br>
<b>To:</b> Justin Hutchings<br>
<b>Cc:</b> <a href="mailto:ipp@pwg.org">ipp@pwg.org</a>; Ira McDonald; Paul Tykodi<br>
<b>Subject:</b> Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments<o:p></o:p></p>
</div>
</div><p class="MsoNormal"> <o:p></o:p></p><p class="MsoNormal">Justin,<o:p></o:p></p>
<div><p class="MsoNormal"> <o:p></o:p></p>
</div>
<div><p class="MsoNormal">Thank you for your feedback! Quick comments inline...<o:p></o:p></p>
</div>
<div><p class="MsoNormal"> <o:p></o:p></p>
<div>
<div><p class="MsoNormal">On Sep 5, 2013, at 6:06 PM, Justin Hutchings <<a href="mailto:justhu@microsoft.com">justhu@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div><p class="MsoListParagraph" style="text-indent:-.25in">-<span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span>OpenXPS has a MIME type of application/oxps, not application/OpenXPS (<a href="http://www.iana.org/assignments/media-types/application/oxps">http://www.iana.org/assignments/media-types/application/oxps</a>)<o:p></o:p></p>
</div>
</blockquote>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">Oops, will fix.</span><o:p></o:p></p>
</div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div><p class="MsoListParagraph" style="text-indent:-.25in">-<span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span>This spec appears to have a bunch of content which is completely unrelated to the transaction based printing. Why are we throwing these into what would otherwise be a very straightforward, to-the-point spec?<o:p></o:p></p>
</div>
</blockquote>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">These have particular application to commercial print services and service discovery.</span><o:p></o:p></p>
</div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div><p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span>Print-scaling-supported<o:p></o:p></p><p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span>Print-scaling-default<o:p></o:p></p>
</div>
</blockquote>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">These provide control over the final imposition/scaling of the document data on the output media - important particularly for commercial print services.</span><o:p></o:p></p>
</div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div><p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span>Printer-dns-sd-name<o:p></o:p></p>
</div>
</blockquote>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">This is used for service discovery; we need to have a way to configure the service name.</span><o:p></o:p></p>
</div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div><p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span>Printer-kind<o:p></o:p></p>
</div>
</blockquote>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">This is used for service selection/filtering - again, if you are looking for a print service that supports the kind of document you are printing, you need this information.</span><o:p></o:p></p>
</div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">(this is also part of the DNS-SD TXT record, but DNS-SD is not the only way to do discovery)</span><o:p></o:p></p>
</div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div><p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span>Jpeg-*<o:p></o:p></p><p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span>Pdf-*<o:p></o:p></p>
</div>
</blockquote><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">These are used to inform the Client of limits for direct photo and PDF printing - having dealt with a lot of commercial print shops over the years, it is VERY important
for the Client to be able to know whether they support a particular flavor of PDF or have limits in the maximum size/dimensions of print files.</span><o:p></o:p></p>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
<div>
<div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Andale Mono","serif"">_________________________________________________________<br>
Michael Sweet, Senior Printing System Engineer, PWG Chair</span><o:p></o:p></p>
</div>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span><o:p></o:p></p>
</div>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp">https://www.pwg.org/mailman/listinfo/ipp</a><o:p></o:p></span></p>
</div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""> </span></p>
<div>
<div><p class="MsoNormal"><span class="apple-style-span"><span style="font-size: 12pt; font-family: 'Andale Mono', serif;">_________________________________________________________</span></span><span class="apple-style-span"><span style="font-size: 12pt; font-family: 'Andale Mono', serif;"><br>
</span></span><span class="apple-style-span"><span style="font-size: 12pt; font-family: 'Andale Mono', serif;">Michael Sweet, Senior Printing System Engineer, PWG Chair</span></span><span class="apple-style-span"><span style="font-family: 'Andale Mono', serif;"><o:p></o:p></span></span></p>
</div>
</div><p class="MsoNormal"><span style="font-family:"Times New Roman","serif""> </span></p>
</div>
</div>
</div>
</div>
_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>https://www.pwg.org/mailman/listinfo/ipp<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; 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; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; 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; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></body></html>